Game mode in multiple standalone windows

Hi everyone,

I’m trying to implement a multiplayer game using a 3rd party backend as service. In order to be able to test on a single machine, I need to be able to test two clients simultaneously.

In order for it to work I can’t use a single process PIE because then the message reception from my backend doesn’t work for one of the client windows, so the solution for testing is two standalone windows, each with its own process (and thus separate connectivity, I’m guessing).

Now, I managed to get this to work, but I encountered something that I think might be a bug in the process, that might be trouble later on.

Here are the repro steps :

  1. Create a new blank project.
  2. Create an empty level.
  3. Create a new game mode (and make sure it’s the one used in Maps & Modes in project setting).
  4. Set up multiplayer advanced settings so :

106193-mpoptions.png

5 In the level blueprint, create this network :

6 Launch as standalone game

In the first window, the cast succeeds, but in the second one it fails.

Now, from what I understand, in a client-server situation, the game mode would only live on the server, so you couldn’t access it in a client (at least that’s what I understood reading here and there).

But that’s not the case here, as these are two standalone (supposedly) client instances, not connected to each other. Each should have its own individual Game Mode, no?

Hello FPSYX,

So if you have the Run Dedicated Server option unchecked, the first player will be established as the listen server.

In this case, player one will connect as the listen server which will use the Game Mode created, but the second player fails because game mode is not replicated to the client. You would need to use something like GameState for the second player (client).

I found some helpful information on our Forums which can help explain this process in more detail. Let me know if you have further questions or need additional assistance.

[Game Mode in Multiple Standalone Windows][2]

Cheers,

Thank you Andrew, indeed that tooltip says it all, I had missed that.

Is there any way I could override that behavior and have both standalone windows unconnected to each other (and both be “server”, then, with access to game mode)?

I tried looking into the command line arguments, but saw nothing that could fit the bill : Command-Line Arguments | Unreal Engine Documentation

(I’m guessing the Server Game Options field would only apply to the first window, so that’s not it.)

Is there any way I could override that behavior and have both standalone windows unconnected to each other (and both be “server”, then, with access to game mode)?

So if each player is marked as play as Listen server then you will have two server type players. The catch is, you want to establish Server to Client functions as well as Client to Server functions which are held in the Player Controller.

It sounds like you are new to Networking and Replication, which is a different monster entirely. I would take a look at our documentation on Networking which will give you a good bit of information on how we handle this functionality.

Networking and Mulltiplayer

More specifically I would look into the Client-Server Model documentation for your particular case. Then branch out to other areas of networking as you go. There is a lot of information and can be overwhelming so take your time to make sure you understand the basics of how client and server communicate and how replication is handled throughout.

Cheers,

The game I’m working on is a turn based card game, and clients don’t have to be online at the same time in order to play.

So I don’t need the players to be connected to each other, only to the server to get/send updates to challenges and do the matchmaking. In this case, my server is the 3rd party backend as a service (Gamesparks).

The Unreal side is only client, never server, that’s why I’d need this behavior for testing.

Does that clarify what I’m trying to do?

You’re right, though, I’m fairly new to multiplayer and networking, and I might be looking at the problem the wrong way.