[ Enquiry ] Getting Startted with Networking

Hello Everyone,

I’m starting this project to be my Test Project and gain more experience in UE4 and programming C++ in the engine. then rebuild all again to start the actual project.
I plan it to have a server for that has a lobby and allow people to make rooms so people join and play together a 2v2 match or 4v4.

My question is…

  1. Is this a good approach to learn networking and the same way to learn the engine inside out?
  2. will mixing blueprint with C++ will be efficient in doing online play? and if not how much drawback will blueprint give?
  3. beside documentation, is there somewhere you guys to start?

I had some more questions wrote them down but I don’t know where is my note >,<
once I recall them i’ll post them sorry ><

knowing I already experienced game developing and experienced OOP programmer for the coding side…


This is merely my opinion, I am not the most experienced UE4 programmer, at all. Hopefully a more experienced user will give you his insight :slight_smile:

  1. No point in learning about the TPC/UDP layer I guess, as the engine already implemented the layer, you should learn about the Reliable, Unreliable, Server,Client,Multicast, etc specifiers and how it works, but in a generic way, the documentation is actually not that bad in this case.
  2. Honestly I don’t like it, at all, but unless you have quite a performance-hungry project it shouldn’t make much difference (but well, Blueprints can be seen as a scripting language, so expecting it to be 4x slower, isn’t an exaggeration I think).
  3. I’d recommend taking the SurvivalGame project, it includes a lot of stuff regarding networking.

Good luck!

My view on 2 is that you can mix C++ and Blueprints with out losing performance. You do all logic and calculations in code, but expose variables for Blueprints.
For settings and BP access to class members, that way you lose no performance and you can stile give a lot of access to designers.

However when dealing with replication, I have found its much simpler in code.

Thanks man I really appreciate the help.
just one more, which survival project you mean?

good to know about the performance, because this is what I was thinking of initially …
Thanks man

and one more thing, is there any recommendations for server hosting companies that are good for UE4? or good in price for starting and later?
and what is the best to go with dedicated server or should I use public one?


This one :slight_smile:

As for the other question, I have no idea and would like to know as well. A few years ago I used Hetzner, but I have no idea if they’re still good.

I got lost of how hes going with his tutorial >,>

I have one more question, do you advise to start building up networking then implementing my game mechanics after the networking is set?
or i can do my game mechanics and then do the networking?


Honestly? I’d start small: mechanisms first, however, design it so I can easily & properly network it afterwards - the structure of the mechanisms should take into account that you will want to network it.

That is what I’m afraid, that i wont design properly then i’ll have a trouble networking it …

Just think of it this way “Who will have to manage this section? Does it need to be authoritative or double checked? Server. Is it purely simulation and accessory behavior? Client.” and split the code accordingly.

Client: “I wanna move damnit” (wants to move), “Well I ran the checks myself, and I can move!” (run checks locally to avoid flooding the server, unless you are running a high-bandwidth and performance server) → Client: “Hey server can I move?” (send a RequestMove to server) → “Well I’ma see if you can move you good-for-nothing…” (run the checks on the server) → “well yeah, you can” (send MoveForwardIdiot(FVector dir) to client); “nop, you’re stuck moron” (send an ActionFailed or just return false).
So the wants to move is Client, the checks, are both Client & Server, RequestMove is called by the client on the server; the MoveForwardIdiot should be ran on the client.

Does that explain it? :stuck_out_tongue:

Horus’s tips are very helpful.
What I can tell you from experience, that it takes a while to fully understand Unreal’s networking. There are gonna be moments when you’ll pull your hair out and rewrite whole classes just to get it to work correctly. But when you finally master it, it’s amazingly easy and fun to use.

Some pro-tips I can give you are:
Replication and RepNotifies are the two best things in the world. If you use them correctly you’ll barely notice you’re writing networked code.
NetMulticast should be avoided if possible (in most cases it can be, but sometimes it’s necessary. Learn to differentiate it from Replication and understand its use)

Also, you have to understand the difference between Authority, Simulated Proxy and Autonomous Proxy.

Say you’re playing a 1v1 match online:
You’re sitting at home at your computer, you’re connected to the server. You are the Autonomous Proxy, the client.
But what about your opponent? Is he a client? No. Your computer just creates him, since the server tells your computer that he’s in the match as well. He’s simply a replicated actor from the server. Your computer however, still runs his code, still “plays” as him. But your computer plays him as a Simulated Proxy, a “third person”, if you will.
The roles are of course reversed at your opponent’s computer.

But there’s a third computer also “in the match”, which is the server. And the server is the master of everything, and has the role “Authority”.

Try setting up a testing level and use these checks to see which role you have, and make sure you understand it. It’s the first step and it’s imperative you know the differences.

AMyActor::BeginPlay() {
       switch (Role) {
       case ROLE_Authority:
       /* Server * /
       case ROLE_AutonomousProxy:
       /* Client */
       case ROLE_SimulatedProxy:
       /* Simulated Client */
       default: break;

Also understand that in this 1v1 match, there are three Worlds (World as in “GetWorld();”)
Your world, the one at your computer. Your opponent’s world. And the server’s world (Although the server doesn’t render any graphics, he totally has a world)

NOTE: This example is for when running a dedicated server. You can also host your own server, which makes you both client and server.

That is great advice!

I’ll add a bit onto that:

  • Usually I say the golden rule is “Do not trust the client, ever.” in UE4, this rule isn’t entirely true as the network layer is pretty solid and it does have linear prediction - this is not the true name, I can’t remember the bloody word I’m sorry - and lastly, you are likely to run servers locally (as opposed to dedicated) and so, bandwidth and performance are very important concepts. Instead of saying “the client is merely a rendering tool”, we will trust it, up to a certain extent. Fortunately, UE4 allows you to specify which items should be passed in a Reliable (full, syncronized, always), this being the case, you can run checks locally, but again, run it on the server as well. If you use the Unreliable keyword, you are automatically saying that you cannot trust that information (that is, the only version of that variable that is guaranteed to be accurate, is on the server), and so, checks on that variable should only be done on the authoritative side - server. My advice: you shouldn’t ‘tag’ everything as reliable, I mean, you will have to sacrifice something at some point, so, if its accessory and doesn’t have a direct impact on gameplay, make it unreliable, eventually it will be syncronized.

Hope it helps!

Thanks very much guys for the tips and concepts presented there. they are sure really helpful.
just one more thing, anywhere i can find practical solution beside the survival tutorial one? because I had hard time “Implementing” it…


Not that I know of. But learning by doing is the best you can do. I tend to feel that following a template tutorial is less worthwhile than experimenting with it yourself.

Problem is, Implementing random functions to prove a concept can be a troublesome, but it seems it’s the only way =D

Thanks Bro =D