Photon or Mirror ?

Hello
I know it's been answered many times here
which of them is better for someone who is total newbie to networking and want to make local multiplayer ?

 

PUN is generally easier to get started in my opinion. But ultimately it will depend on the type of game you are making. PUN has a cap on network msgs, I think it's like 500. So that ultimately limits the number of characters/objects that you can sync across the network. If you have a turn based game or a game with few players and network objects, that may be just fine. You also have to pay after you hit 100 ccu (which I believe still comes included with the paid version of PUN only). 100 ccu is pretty generous, and you would have to pay to host your server anyway with Mirror. I think Mirror really shines if you are looking for authoritative server style games. It is most similar to unreal's networking solution in that sense. With PUN, one client is always the master, there is no server. Another case when mirror would be useful is if you are publishing it to steam and the client can also act as the server. Then you can use steam's relay and essentially never have to pay for ccu or hosting a server.

 

ok so ill try pun, thank u

 

Although you make some good points I have to point out that this is incorrect.

When a user "creates" a room it is running on Photon's servers but it's not persistent. It only exists whilst players are connected to it. Once everyone leaves the room (server instance) the instance is removed. The user who created the room is considered the Master Client (However, they do not act directly as a server/host like P2P solutions).

So with that setup you can have server-based rooms but you can not do things like "allow players to build houses" because, once everyone leaves the server instance, it ceases to exist (as it gets used by someone else on the Photon network).

So it's a kind of hybrid between Peer-2-Peer and authorative, dedicated servers.

 

I apologize ahead of time, but I have to correct this myself. You most certainly can create persistent player owned objects. MMOs and Survival Games do not add player owned assets to the scene (although one certainly "could"), they are kept in a persistence file or database entry with two keys, one key for the player, and one key for the scene. Then they are spawned using logic from your source code when the scene gets spawned. The logic is in the code, not the PUN service.

 

Neither.

https://doc.photonengine.com/en-us/bolt/current/getting-started/overview

 

+1 for bolt if you want simplicity. But also should point out - simplicity and abstraction dont really always help with networking depending on the project and needs, thats why generally its better to have someone knowledgable on the team with networking.

You will get ease of use, but you lose a ton of power and flexibility as a result. For what you want to do, it should be fine, but important to understand why this and photon exist as seperate products and the differences.

Secondly, you mention local multiplayer OP - you dont need networking for that, unless you meant something other than local multiplayer?

 

If you want to scale I believe a custom networking solution is a big plus. It all depends on the networking skill in the team.

 

The post you're responding to is from october. Not the worst necro-bait out there, though.

 

Plus none of these solutions will truly enable you to move that far beyond the stage of "total newbie" as none of them teach you networking.

 

Yup exactly. Sort of the same as the issues with shader graphs (and graphs in general). Just because the way you assemble it is now easier, does not mean you suddenley do not have to learn the concepts. Learning the syntax / how you put it together is rarely the hard part, its the actual concepts etc behind everything and reasoning for why decisions are good/bad in certain context. Essentially, there is never an easy way to avoid learning the thing you need to do in game dev

But lets not scare OP off too early, we all start walking before we run and once they give it a whirl I am sure they will quickly find what they need to learn and what is feasible at their skill/effort level

 

To be honest I was tempted to recommend learning sockets instead of using an existing solution since local multiplayer shouldn't have to worry about advanced concepts like how to deal with latency.

 

True, could be a decent approach - but if OP is not a strong coder it could still be a bit scary at first. I mean sockets in general are not really that complicated, but I remember first seeing socket code (baring in mind this was probably more than a decade ago and I know things are much more simplified now) and thinking "F*** that" - was not until a couple years later that I had another crack and realised the concepts themselves are pretty simple (when as you say, you are not worried about latency etc)

EDIT: yikes, I feel old. This was probably 15+ years ago. Urgh

 

I can really recommend using low level API for example we use Steam networking which is bound to steam but you can also use their abstracted version which is steam agnostic https://github.com/ValveSoftware/GameNetworkingSockets

It can scale to any size

 

TCP/UDP sockets have been the same since the 70s

edit: Though the libraries at the transport layer maybe have become easier to work with?

 

Yep. Thanks to C# he should be able to just hook up a serializer on both ends once sockets are working properly and then pass his data objects back and forth through it.

 

In all honesty, here is the roll up.

1. Mirror for absolute beginners, or those who really don't want to understand networking. (Mirror is not true client/server, it's peer to peer with a configurable game host, that's NOT the same thing as client/server just because the settings says so)
2. Photon/PUN for people who want easy setup and a service to host.
3. Write your own network stack, there are several youtube videos out there showing you how. This is for the advanced programmer and network engineer or for beginners who are willing to dig in and learn and take the time to understand how and why it works the way it does. This is option #1 for most AAA game shops.
4. Darkrift2 for a very lean network stack that is extensible if you understand how to write network code and to extend it. (not for beginners that aren't ready to deep dive into how it works), it's server code and client code, not a complete solution, but that's what makes it perfect for advanced users who want the fastest network software.

Why did I put DarkRift after write your own? Because I think you should learn to write your own before picking up DarkRift. Then you might ask, then why pick Dark Rift at all? Because it's written cleanly, properly, in easy to understand source code (assuming you can read networking source code, hence #3 coming first). It is excellent at operating networks and a core server or core cluster as fast as the hardware can handle. Dark Rift has simply been written very well, and is optimized for performance. It was not written for easy of use for the gamedev that isn't willing to truly learn networking. The only way to get a faster solution would be to write a network stack in old school C.

#3 and #4 also allow you to build headless servers, that is...servers that aren't running unity (nor even have it installed). This makes for a much faster server if you are willing to learn to write real C#/.NET applications (or other language for that matter).

 

Hi , I m doing a board game with mainly Cards as objects, what networking systems do you recommend ?
Because I tried with mirror and it’s not working well :/ .

 

For a card game you could basicly use rest

 

Absolute hogwash.

Many authoritative server games are built with Mirror offering a true client/server architecture.

I am busy migrating my racing game's multiplayer from Photon to Mirror, and the new version is completely authoritative with only the player keyboard inputs being sent to the server, there is no peer to peer communication whatsoever.

And I wouldn't call it for 'absolute beginners' either, its actually a rather powerful framework for making multiplayer games and I have 11 years of experience using Unity with several multiplayer framework integrations under my belt, unless of course that still only qualifies me as an absolute beginner....

A headless server is not a 'server that isn't running Unity'. A headless server instance is a build that doesn't require a graphical interface.

You can easily run and deploy a headless instance of your game build that uses Mirror as your networking framework. Unity doesn't need to be 'installed' on the server first.

 

Thanks. I was looking into this today for adding a multiplayer to our just released game for one of the levels. I will probably now go with Mirror based on this post. It would have ten "racers' and involve collection of rigidbodies and roller derby style interaction between competitor teams., so I imagine I would just grab the keyboard/gamepad inputs from everybody, run the sim on the server and pass the networkTransforms and object instantiation back to the game instances. Is that correct thinking on an approach?

 

How is the user experience? I know DayZ does this too, and I hate it when you are desynced and rubber band so badly that you crash.

 

Absolutely spot on.

From my experience running one physics simulation on the server is the way to go. Previously with the peer to peer model there was all sorts of weirdness with multiple physics simulations running, especially around collisions.

It was also hard to keep things in sync, if I had two trucks racing next to each other at high speed, on one client, it would look like you were ahead, but on the other client, it seemed they were ahead. I really found no solution for this, and played for hours with velocity-driven syncing and extrapolation with SmoothSync, an asset I can highly recommend BTW for syncing your objects across the network and smoothing things out, I'm not sure where I'd be without that asset, and @thegreatzebadiah is an excellent asset author and gives fantastic support.

But with a combination of the server handling the physics, and sending resulting transforms to the clients and using SmoothSync, I'm very happy with how things are looking.

I'm using the 'Ignorance UDP' transport layer for mirror BTW. That's another thing I like about Mirror, is you can use whatever transport that best fits your use case. For WebGL builds you'll need to obviously use a layer for WebSockets, but that stuff is all abstracted away from you, in regard to the calls etc.

 

As I mention in my previous post, with a combination of the server running the physics simulation, pushing the resulting transforms to the clients, and using the SmoothSync asset I linked, the experience has been silky smooth, and the sync is near perfect. I've even tested at 50-100ms ping and it still looks really smooth.

 

Setting this up with an authoritative server where I grab inputs from clients and use those to drive the vehicles in the sim so I have a question. I have several levels that are solo campaign mode and an extensive UI. The sim will be on the server. Do I just build the server game level by itself without the solo mode levels & without the UI to run on the server or do I have to include the rest of the game levels. I am running this thru Steam and I am using Facepunch.Steamworks to deal with Steam for friend invites, matchmaking, the bells and whistles their users expect.. etc. Is my server on Steam or do I choose somewhere else..or what? Or do I need to rephrase my questions?

 

I would highly recommend having a completely separate project for your server build.

Have you thought about how you are going to scale when you need the resources to do so?

I researched several multiplayer server solutions, Unity's Multiplay never back to me when I used their contact form. Amazon GameLift had so much documentation, I felt like I was studying for a thesis, and their Unity SDK support seemed flaky. Dedicated/bare metal options didn't seem flexible enough.

EDIT Sep 2021 : For a server solution, I ended up going with Edgegap, they offer a containerised solution, but at a much higher level than something like Agones, where you have to run all your own commands/scripts etc. You upload your container to their registry, and it automatically finds the best server among their 200 or so locations what will give all matched players the best latency. What's also great, is they have integrated OpenMatch for match making and built a wrapper on top to make it much easier to integrate. They have no monthly costs, and you only pay for containers that are up and running serving game sessions. After signing up I was invited to their Discord and their whole team has been very helpful.

So to your original question, since I needed to be able to spin up containers quickly as demand dictates, I needed a server build that was lean as possible. I have two separate Unity projects, my game client, and my game server.
The game server has one job, to handle the physics simulation, race logic, accept inputs from the clients, and send the race results to my backend server (GameSparks).

Here are some benefits about having a separate, lean server build...

A lean server build takes up less resources, and is faster to spin up, and cheaper to operate in the cloud

This server build is truly authoritative, it can prevent cheating, as it calculates/simulates all results, and can securely send these results to your backend, without those results being touched by any client, nor does any code exist in the client that someone could perhaps reverse engineer to send/simulate results.

The server build has no assets, except the physics objects and scripts in the scene required to run the simulation.

For instance, this is what the scene of one my tracks looks like in my server build. The only thing that exists in the scene are the meshes used to generate the colliders in the scene. The server is built as a Linux standalone executable, and uses the 'Server Build' option in the Build settings to make it headless.



Here is the exact same scene in the game client...



Another benefit I found with having a separate server project, is it was helpful to have two Unity editors open, with one editor running the server, and the other running the client, which makes for easier debugging.

Well I hope I answered your questions, good luck!

 

I agree about having just a physics object based build as authoritative on the server running the sim.

So..players have multiple solo levels and one MP level. Server has one MP level. Players meet in lobby and create teams and then they load the CycloDerby scene and the server spins up that one scene. Game on server is Cyclotronica stripped of all other levels and built as server. Mirror networking will resolve the comms between the client with multiple level instances and the server instance of one level.

Thanks or the tips. It is indeed thesis level stuff just figuring out which combo to go with and what subset of that is needed. All tuts are all bells and whistles so those have to be filtered for the gems needed.

 

Depends on use case. I dont think this would look good with server side physics for eample

We distribute physics to clients that currently own entity and validate sanity on server

 

I don't see anyone mentioning it, but I think for something like Racing game you'll need movement prediction. Mirror doesn't do this by default.

This is related:
https://forum.unity.com/threads/making-player-movement-secure-with-mirror.829683/

 

@Meltdown pointed out an asset that handles interpolation and extrapolation, transform and float compression and has dozens of 5 star reviews as a drag and drop, set a few checkboxes component and folks trying to tune their games for months got instant relief with smoothed motion. Still figuring out the setup as I build the derby track, emitters, hazards, environment efx and props but basically once the level is finished and I finish the duplication of the vehicles per team and make them easily discernible with team badge and "jersey number/nickname" this is the plan.

Duplicate the Scene - Server runs the sim so the UI is taken out, lighting removed, materials removed. It is only running a physX sim and reporting back positions, rotation, collisions, triggerings and gameObject instantiations and destructions based on collisions. Clients physics components are disabled as their positions and rotations derive from the server sim. Instantiated object still retain particleSystem and graphic/sound efx.

The client will only send horizontal, vertical, braking key and gamepad joystick input for navigation, switchWeapon and fire input. The Server sim will sort received inputs and send them to the target vehicle, tick to the next frame and send the transforms, instantiations/enablings/activations and destructions/disablings/deactivations back to the clients. Score is kept up to date on Server and sent back to Clients when any value is updated.

Sounds simple....heh.. I have said that too many times and ended diving into deep wells. I have fortunately made most prefabs self actuating in that once instantiated they know what they should be doing, how long to do it, when to exit and whether any next of kin need to be notified of their ultimate demise.

 

Might be easier to start with a single project and do it the Mirror way with the single project for both, BUT given that @Meltdown (IIRC) worked on a racing game, he's likely more experienced in the matter.

(Opinion)
Also, in my opinion, sending input to the server is mostly suitable for situation when you're playing on LAN. If you're playing through the internet, the client can experience high ping which (70...200ms), I believe will make the vehicle very hard to control. I used to play some racing games in the past and I think that handling input on the server is highly likely not how at least some of them worked. Basically the user shouldn't be allowed to teleport, but there should be some leeway in control handling.

 

It isn't just racing. There is a whole world of subatomic physics going on as well as weapons, hazards and lethal entities. I don't think a host can coordinate it all and run a client at the same time. I do think a fast server can run the sim minus the UI, lighting and materials and report back the results pet tick. The SmoothSync asset can handle the extrapolation. The client is doing nothing but updating transforms and keeping track of which prefabs get created and which destroyed.

I am looking into using the Linux Labs cluster as they handle high end clientele that need the fastest servers with the lowest latency. They wanted to branch into gaming and I ain't using google or amazon. Cancellers get cancleled from cashing my cheques.

 

(opinion)
Host can't and shouldn't coordinate it all, but if the car is about to be rammed into a wall and the driver tries to swerve away at the last moment the expectation is that the car is going to react right away and not 0.2 seconds later.

In the past, in case of High Ping situation the general experience was that avoiding static track obstacles still works as normal (meaning it is at least partially performed locally) i.e. immediately, BUT other players are something you shouldn't approach, as they're a big ball of a probable accident. A kind of moving Schroedinger Obstacle. It is also worth mentioning that stuff like non-blocking ragdolls typically is being run locally.

Obviously if you're trying to make rigidbodies part of the gameplay and expect nearly-LAN connection quality things are different.

Aside from that server authoritive move is more often used on "point and click" to move kind of games. Like MMOs, RTS and so on.

Either way, just throwing my 2 cents in hopes something is useful.

 

Yeah I cant see a fast paced game work well with this level of server authority

 

There is a lot of tweaking involved, I in fact have some physics running on the client too, to handle immediate client-side input, but the server authority ultimately corrects it.

But having this client-side physics, eventually being overridden by the server physics, still gives a fairly good, responsive feel, its not perfect, but with enough tweaking and mucking about, you can make it work.

Multiplayer is mostly smoke and mirrors.

 

Can you give us a brief of the rigidbody and physics objects you felt could be executed on the client side? Did you remove the rigidbodies from your vehicles and have them by updated by their transform position and rotation based on the server sim? Or did you use SmoothSync to update the rigidbodies velocity and angular velocity?

 

It will really depend on your physics, but I found just having steering working client-side helped a little, but you really need to play around to see what works for you. I spent many, many hours tweaking and playing around with settings.

 

I too am in a dilemma of choosing the best solution for my Unity based application, its not much of a game but rather a meeting place, where a large number of people can login in a virtual space and interact with each other, there is not going to be any inventory or game logic. What solution would be best to develop a quick prototype? Thanks

 

Just use Mirror, or Mirage which is Mirror with a better API.

 

Thanks, i have started checking out Mirror, any idea about voice/video chat over mirror?

 

You can google "Mirror voice chat", you know?

You can also roll your own. The simplest way would be to dump voice audio data over network, and then feed it either into either AudioClip.SetData(), or OnAudioFilterRead().

 

I just wanna say that this thread has been informative. I've only got a little over a year in Unity experience through courses and tutorials but have a project in mind and this discussion has been insightful. Thx

 

Here is an update to my multiplayer server solution, originally I was going to go with Agones, but felt it was too 'low level', where you have to run all your own commands/scripts to spin up and down clusters/servers etc. and it didn't really have any support aside from one guy at Google who was the champion of the project.

I therefore ended up going with Edgegap, they offer a containerised solution, You upload your container to their registry, and it automatically finds the best server among their 200 or so locations what will give all matched players the best latency.

What's also great, is they have integrated OpenMatch for match making and built a wrapper on top to make it much easier to integrate. They have no monthly costs, and you only pay for containers that are up and running serving game sessions.

After signing up I was invited to their Discord and their whole team has been very helpful.

So if you're looking for a server solution that takes care of all the lower level work for you, give these guys a try.