Download

Server listener question

Not sure if this is the correct place to ask, but something that’s started to confuse me a bit while doing some c++ network code and reading the docs.

Been reading here : Networking Overview | Unreal Engine Documentation

I always thought unreal (server-listener) concept was:
I am Host, I start the server, and that’s it, my Pawn spawns and Controller. Im in the game/level running around.
So right now 1 Server exists, 0 Client(s).

A Client joins my Server, spawning them a Pawn and Controller.
So now there’s 1 Server, and 1 Client.
They’re running around, and some bits are (to keep things simple) happening on my Server and replicated back to them etc…

The bit where I’m slightly confused is, do I as the host/Server also spawn a Client that connects to my Server - thus I’m also having my Pawn replicated from server back to my client?

https://docs.unrealengine.com/Images/InteractiveExperiences/Networking/Overview/ClientServerExample.webp

The image used in the documentation, as an example, suggests to me that for 2 players, there’s 1 Server and 2 Clients.

In the Listen Server model, the host is a client and the server at the same time. When you as a player host a match in this model, you create and run the server on your machine, but you still connect to it as a “client”. Rather than thinking about servers and clients, think about them as different Worlds (or instances of the game running on different machines). There’s a World with authority (the host’s machine aka the server), and Worlds without them (remote machines). I guess the logic is: Why start a headless server and then connect to it immediately, when these two steps can be combined?

Ok, so this is why in the docs picture it has 3 displays, 1 for server, 1 for server-client, and 1 for client?
When I start a Server and join as a “client”, and someone else joins as a “client” , over the net, are those kind of… different client types?

No, I don’t understand why they have 3 screenshots there, it’s very confusing. All clients are the same, but they can either have authority over something or not. I suggest you check out the Unreal Engine 4 Networking Compendium.

@STRiFE.x ah yeah I’m comfortable-ish with clients owning things.

But was confused by the diagram with 3 screens. This is why I was asking if the host has the server and has it’s “own” client which they play through in the server

It doesnt seem like they do, just seems the player is playing the game with their instance set as server, and it broadcasts back out

This is not exactly 100% correct – the client is not a separate process from the server when used as a listen server, and as such, there can be some subtle differences between how you write certain code. Sometimes you have to distinguish between network client, network dedicated server, and listen server.

no, i don’t have any examples, as i haven’t written anything using that in about a decade now.

^ This ^ …

That wall-of-text from Epic above isn’t very helpful. Since a Listen-Server’s Client = IsServer / HasAuthority, it can lead to confusion. Epic offer helpers to help. But they don’t document using them all together in practical examples. Instead you can infer owning / remote network client or server by using a combination of logic. Here’s examples fwiw:

Standalone Singleplayer:
IsStandalone = true && Gamemode -> GetNumPlayers = 1

Local Offline Multiplayer (on same screen or split-screen)
IsStandalone = true && Gamemode -> GetNumPlayers > 1

Network client (server client):
NOT IsStandalone && IsServer=true && IsLocallyControlled = true

Network client (owning local client):
NOT IsStandalone && NOT IsServer && IsLocallyControlled = true (ROLE_AutonomousProxy)

Network client (remote client):
NOT IsStandalone && NOT IsServer && NOT IsLocallyControlled (ROLE_SimulatedProxy)

Cheers guys for all the info. So @UnrealEnterprise you say “Since a listen-server’s client…”, so does that mean a Listen-Server does have it’s own client? And like @eblade said, the difference is quite subtle and it’s not the same as a Network Client?

This kind of makese the most sense to me, I think…
I start a server game, I connect to it as a local client, internally… or something? Based on examples above, that would be my Network Client (server client) ?

@axelZellalex

So, how is a Listen-Server Client (LSC) different to a remote network Client?

The LSC has ‘super powers’ and can access Gamemode and Player-Controllers for all players, whereas none of the other ‘remote clients’ can. Plus the LSC can enact changes in other ways. The LSC is the level, so if you mod the map, things will change on all remote clients. If the LSC changes materials on its own Pawn, that will often force an update too without needing a Multicast. If the LSC spawns an actor or something with replication enabled, that’ll also auto-update everyone.

Plus the response time is also different obviously. So its like being a ‘super-client’, and you have to account for that, as the server client is generally the first to know everything. Summing things up overall, the LSC doesn’t have to make RPC requests, or explicitly take ownership of anything, because the LSC Is-The-Server. So it gets all the right updates and everything just works and looks right and behaves correctly by default - as you’d want and expect to see in a multiplayer game.

The problem with that is that it means you have to keep testing with two actual remote clients all of the time, to ensure everything is actually working, and ignore most of what the LSC is doing. If you’re just making a 2-player game that can make things easier, so it just depends. But when converting a singleplayer prototype to listen-server, the latter will act like singleplayer, however the code for all the remote clients will have to be totally redesigned. This also mentions a few other aspects.

A Listen Server is simply a Server with a local player. There is no “internal” server and client connection, there is ***only ***the Server.

If no other players connected to you, it would effectively be the same as Standalone for mosts intents and purposes.