How do you make FPS Microgame multiplayer?

I was playing a game I made with FPS Microgame, and I was wondering if you can implement multiplayer in to the game. If you can link a tutorial or code release that would help a lot.

 

The short answer is: if the game wasn't built with multiplayer in mind, it will be twice as hard to add multiplayer to it.

There are some new frameworks that are trying to make it easier to do this like what NormalCore (now focused on VR) and KinematicSoup (their product is still in alpha / beta stage) and probably a handful of others -- but the long and short of it is still that as of right now, there is no easy way to add multiplayer to an existing game.

Add to it that building a multiplayer game (and making it work as well as your players are going to expect it to) is a whole new skillset on top of just building a good game in Unity. There currently just isn't an easy way around it within the Unity ecosystem that I've found.

If you want a good starting point for a multiplayer game though -- and you are just getting into Unity -- check out the DOTS FPS Sample (EDIT: Link removed, as I was pointing to an old project, see updated below) that was built by Unity to show off their new DOTS game and network stack workflows. With that said, I wouldn't imagine that DOTS network is any easier than building a multiplayer game with traditional GameObject workflows and you won't find as many tutorials around DOTS, as it is still brand new and evolving quickly -- but at least that is a full game sample that goes end to end FPS with multiplayer for you to pull apart and learn from.

 

I do not think that the 'FPS Sample' you are linking to uses DOTS. Did you mean this one: DOTS FPS Sample

 

Thanks for the link. My link was to the old FPS Sample announcement page in 2018 (which uses ECS, but you are correct that it didn't claim DOTS -- and also it apparently isn't updated for newer Unity version, so please ignore).

I should have just linked to the github to the one I was thinking of:

https://github.com/Unity-Technologies/DOTSSample

(edit: for clarity)

 

Sorry for being pedantic Apart from that, I do agree with everything you said in your original post. Good multiplayer is damn hard. (well, it has been for me in any case)

 

It is for everyone. There are just SO many edge cases, and you have to think about a much broader domain of things than you do with a single player game (networks, servers, firewalls, Nats, data sync, data serialization on the server, user Auth, and the list goes on).

And on top of the technical challenge, if you want any part of your multiplayer to be persistent or hosted on a sever, that drastically changes your business model on how to make enough money from the game just to keep it alive long term.

 

To expand just on this one point. Nearly every system in a networked multiplayer game has to have networking as a central part of its design. If you're taking an already nearly complete game and trying to add multiplayer, that means you're going to have to redesign and rewrite almost everything in the game.

Lets take just a very simple example where they player wants to pick up an item and add it to the character's inventory. Maybe it is a gun on the ground, but doesn't really matter what it is.

Single player system:
1) Character is within range of item and presses button to pick it up
2) Item is added to inventory system, and represented on the character's UI as in inventory
3) Item on the ground is destroyed

Here's a pretty over simplified version of how the system might instead work when you add multiplayer:
1) Character on client is within range of item and presses button to pick it up
2) Client sends RPC to host requesting to pick up item
3) Host verifies item exists and is within range of character
4) Host adds item to host authoritative copy of character's inventory
5) Host destroys item on the ground, and sends RPC to all clients to destroy item on ground
6) Host sends RPC to client which owns the character with an update to the character's inventory
7) All clients receive RPC to destroy item on ground
8) Item on ground is destroyed on clients
9) The client which owns the character receives RPC to update the character's inventory
10) Client processes RPC, updates client's copy of the character inventory, then updates the UI to reflect the current inventory

All along the way there are different cases you need to check for. What happens is the player tries to pick up the item, then immediately disconnects from the host? What happens if the host receives a request to pick up an item the character is too far from to pick up (are they hacking)? What happens if the item was already picked up by another character by the time the host processes this request? They can't both pick up the same item.

You have to go through the same thing for every single bit of the game, every single interaction the player has which involves talking to the host. So you're basically redesigning almost the entire game.

 

But with all that said -- don't let that stop you from taking a step back from the FPS game and taking a stab at building a multiplayer FPS. You will get to re-use a lot of the assets (and even a few of the prefabs) you used in the FPS project, and that means you are closer to building a multiplayer FPS and developing your own skills at building both a good game and a good multiplayer game.

Just be aware that it is a lot of work -- commit to it -- and then post if you run into any blockers along the way

 

Doing really good with the Multiplayer though, my singleplayer game with FPS Microgame died . But thats fine, I just want to make an FPS Multiplayer game anyways

 

Would use mirror, but I can't pay the 20$ a month for the server list though

 

Why not use Photon's PUN? You won't have to rebuild your entire game to make this work if you're simply talking about making the fps microgame work on a multiplayer level...

 

I'm probably on record (perhaps even in this thread) of saying that taking an existing game and making it multiplayer when you weren't intending it to be multiplayer from the beginning -- the development of your game isn't going to be just twice as long as the single player version would be -- it will be at least 3 times longer.

So if it takes you 1 month to build a your core game mechanic in Unity for the single player game, assume that you will spend at least another 2 months to make that core game mechanic work bug free in multiplayer.

Beyond that, the actual choice of which engine you use (Mirror, PUN, or Unity's official MLAPI) is up to you and they all have plusses and minuses.

 

hmm
i do no

 

In a typical netcode solution, this is probably the detail that one needs to think when developing for networking. But I am currently implementing a solution that simplifies the effort to the following:

1. Character on client is within range of item and presses button to pick it up
2. Character state is continuously sent to authority (server or hosting client) including button presses, position, aiming vector, etc.
3. Authority detects character is within range of item, sees button press signal, and performs pickup on its character replica locally.
4. Netcode replicates the items' state across all clients to match authority.
5. [EDIT] If the asset is to be made invisible, I deactivate it, I never destroy it. In either case (visible or invisible), the authority's role in replicating of the asset's state is disabled while the asset is owned by a Pawn (has a parent reference on its transform).


To accomplish 4 above, the developer needs to specify those existing properties and add new properties that need to replicate across the network.

Adding a property such as the Pawn that picks up an asset (becomes a parent to the asset) for replication can be as simple as adding the following property to an asset script:

Code (CSharp):

1.  
2. [ReplicatePropertyToClients]
3. int ParentId
4. {
5.     // read by netcode layer on authority to be sent to clients.
6.     get => transform.parent == null ? 0 : transform.parent.GetComponent<Pawn>().Id;
7.  
8.     // written by netcode layer on clients
9.     set => transform.parent = NetcodeApi.GetPawn(value)?.transform;
10. }
11.  

I mention this because in my efforts to roll my own netcode, I found that as you and others suggest, netcode solutions today are a foundation to build upon, not an Asset that you can just slap into an existing project. But I am trying to get to the latter paradigm as much as possible. What I described here is what I am currently working on at the moment and it seems to work well.