Multiplayer Server creation/communication


I’m looking for some options to create a multiplayer game. My intention is to create my own dektop application that would act as the game client. Meaning I would handle users, their data, configurations, menu stuff and all that.

I’d like to code my game using unity, preferably with multiplay. My question is how to propperly connect the two applications, here is a theoretical example (I have not found a way to make this work).

A player logs in and ques for a game in my client app.
My client app is in charge of matchmaking and all that good stuff.
It finds X number of players to fill a lobby and connects the players togethen in the lobby (game preparation and stuff).

Once the game is ready to launch I’d like to create a server instance with specific config for that game (for example the ids of the players in that lobby, what they choose to play as… And of course everything linked to these specific players).

I’d like to then launch my unity clients, with the Id of the player and the id of the server they should connect to.

From then on out the server does it’s thing, allows only the players that it’d recieved when created, loads the map and the match starts.

Once the game is over, the server should then notify my app, somehow, and close itself (also, the unity app should also close, but it does not need to be automatic). My client could then show post-game stats and stuff sent by the game server (brfore it shut down).

If any of you are familiar with league I’m going for that style of flow, but without their shitty ass code xd.

I’ve looked into the Unity services Web API, and I’ve seen you can create server configurations and builds on demand, but I’m hesitant because of a couple things:
I’m not convinced that would be fast, and even though I don’t need it to be very fast, I don’t want to make players wait for 5 mins to get into a game.

I’m also under the impression that these configs and build would then be deployed into a fleet, but I really only want the one server for a specific match. (Is there any way to send data to an existing server intead of creating / destroying them contantly?).

Even if what I just mentioned was possible, how could I then say to my app that the match finishes? Is there any reliable way to make HTTP requests though unity?

This is a theoretical way this could be done, but I’m aware that it may not be achiavable. I’m open to other ways of acomplishing a similar goal.
For example, I’m aware I could use sockets for app-to-app communication, but they are heavely unreliable and I’d appriciate some alternatives.

Also any help on how to open a unity app from another app while passing some basic info would be greately appriciated.

Thank you in advance if anyone has any idea how to achive this.

Hey there,

well there is a lot to unpack here so i’ll try to answer everything - might be some word salad though.

Lets break this problem down into multiple things and give them names. You want:

  • basic multiplayer gameplay with a dedicated server
  • matchmaking
  • server-scaling/server-spinup
  • game launcher

This is basically what you wrote about. The gamelauncher is your place to start and wait while matchmaking is inprogress (just like league). The matchmaker starts/spins up a server instance and then all players start a client and connect to the server to play the game. When the game finishes the server can then notify the clients about game-end results for example.

So much for the basic idea in clear words.

Lets start at the start: the launcher. While i don’t see any benefit in choosing the league-architecture this can definetly be done. You can build an application (with or without unity) and have it start a unity game. You can give startup parameters to unity when you launch a game - this can be an easy way to provide certain info (in your case for example the game-id/ip to connect to) into the game client itself.

Then you have the matchmaker. Here you wrote that you want to do this client side: My advice would be to not do this. Whatever is critical infrastructure should not be in the hands of the client as the client can never be trusted. Also you will need some centralized point where players can sign up as “searching for a game”. Otherwhise how are you to know who in the world wants to play? There are services out there who can to that for you - you can also create your own matchmaker and connect to it using http for example.

Regarding servers and server-scaling you will want to use something like a docker based instance. Docker allows for easy scaling and there are many gameservices out there which allow automatic server spinup/scaling with docker-based servers. Together with instances held “pre-warmed” and idle this can allow players to instantly jump into a server and to always have one ready. Be aware that this is can be expensive though. You will need a good budget plan here. If you choose to try and create this system on your own: While this can be done on a lower hard-cost budget (so not counting working hours, just hard cash) it will require extensive knowledge about servers, docker, network communication as well as server maintenance. It might also cost the rest of your sanity - you’ve been warned.

Assuming you have all the above in place then the process can look as follows: X clients start the launcher and sign up to join a game → (as i said here you need a cerntalized point to provide or process this info) → the matchmaker can then simultaniously a) reserve a server from the game-service b) send this info to the clients → they can then launch the actual game client and connect to the server

For the post-game info i’d propose to write this info into some database - this way the clients can poll the info when they are ready for it and receiving that info does not require the client to be still connected to the server when the game ends.

Sidenote about http and sockets: I don’t know where you got the notion that they are unreliable. In the end the network protocoll/communication method you choose should be fitting for the game you want to make (so a big question here would be how much latency you can spare)

So in the end for communication between launcher and matchmaker http can be fine, using a constant tcp/udp connection can also work here. For client-server communication you want something tcp/udp based. As packages i can recommend to check out DarkRift2 and Mirror.

Then you will want to have some webspace with some databases where you connect using http to get stuff like player info (level, xp, inventory, currencies…)

That was a lot of words, let me know what you think.

Last last and general advice for multiplayer games: Only start when you have a really really really good plan (also timewise) and are really really sure that you can make this. Do not attempt this if this is your first real game project. Double all time estimates. Be prepared to spend some money - multiplayers services are sadly not free.

Hello, Wow, thnk you for the quick response!

First of all I’d like to clarify why I want to go with the client/game architecure, bacause at first glance it does sound like more trouble.

I’m a web developer, even tho I have created some unity games, my profession is in web dev, and I love it. My decision behind making a separate client is so I can write eveything in TypeScript with React Native, since the Client would be everything in the game except for the actual gameplay. If it was a perfect world I’d write everything this way, but I need a game engine to write the actual game and that’s where unity comes in. I’ve thought about making everything in unity directly, but I havn’t found any particualrly good solutios to make player authentication and the overall data handling like I want.

To clarify what you pointed out (excuse me because I forgor to write it), this “client” would be a client for my own backend. Connected via http requests and websockets.

This backend would handle everything, from player regstration/authentication, to match history, inventory, matchmaking…

I was unsure that I could launch a unity app with parameters, but I appriciate you telling me that and I’ll do some research into it. This solves the part of the puzze where I need the unity game client to instantly connect to the server with the credentials and gameId…

In the past I’ve created my own dedicated server as a window console app for a unity multiplayer game, opening tcp and udp connections and writting/decoding packages directly in the code. It’s fantastic the control it gives you, but I’s such a pain in the ass. I also had issues when it came to unreliable connections.

I’ve used mirrior in the past, back when unity latest multiplayer solution was uNet, but when it was already depricated, and I’ve also tested a bit with photon. My understanding was that multiplay was the new solution, making mirror a solution of the past since we now have a native one, but I guess that’s not it if you say that.

I’ll probably use websockets for the app client / app backed, but I don’t think I’ts the best solution for the game client/server, since I’d like as little latency as possible and maximum reliability. I’m aware that multiplay might not be the fastest, but I understand it can be reliable.

Do you think going back to writting my own dedicated server and writting packages is my best solution here? Regardles of wheather i create a multiroom/game server or a one-off server with an acompanied service to assign them, it’d deffinetly give me the freedom to connect it to my app backend/app client.

I think DarkRift could be a great solution aswell, and I’ll definetly look into that. Maybe a good solution Is to use DarkRift in standalone for the game server, unity for the game client and keep the app client/server as my own apps, that way I use the network usability of darkRift, while keeping the freedom to make any and all communication to my front/backed, and keep the low latency for the game itself. I hope i wrote that well ahahah.

What are ytour thoughts, is this a good solution I shopuld explore? If so, do you recommend a multiroom dedicated server or the one-off model? If you think the one-off model is better, could you point me to some of these services that you described here:

Docker allows for easy scaling and
there are many gameservices out there
which allow automatic server
spinup/scaling with docker-based
servers. Together with instances held
“pre-warmed” and idle this can allow
players to instantly jump into a
server and to always have one ready.

Thank you sooo much for your time!