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?
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.
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.
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:
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) ?
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.