Mirror - Open Source Networking for Unity

just wondering how do you deal with orchestration is there any providers we can use mirror networking with?

UNET used to have host migration when we forked it.
It was always broken and super complex, so we decided to remove it for the sake of stability.
Probably best to host dedicated servers if you need to.

Google cloud, AWS, Multiplay etc

Mirror II nearing release!

Preparing for the CCU test.
The setup will be built in, for everyone to reproduce.
Will compare it against original Mirror first.
Gonna set up some bots + servers this weekend and get the first results.

Quite happy how it all turned out.
Much more pleasant to work with than UNET back then.
Both for stability, performance, code complexity etc.
Dunno if you guys are gonna like it, but I really am looking forward to using this for my two projects :slight_smile:

Video:

1 Like

Hi, vis2k.

I’m just wondering if the Mirror dev team is planning on adding a built-in framework for client-side prediction and server reconciliation. It seems like other solutions such as FishNet and Netcode for GameObjects are starting to adopt this as a feature, and it would be really nice for it to come to Mirror as well, as it’s one of the most vital features for a smooth and secure multiplayer experience. I and many others would really benefit from this feature being added.

Is this something you’re looking to add in the future? Is this something that might be added with Mirror 2?

Thanks for your time.

2 Likes

When we started using UNET for our games, the two main issues stopping us from releasing were stability and scale.

  • Mirror solved stability, and improved scale quite a bit.
  • DOTSNET and now Mirror II exist to solve scale.

Lack of client side prediction hasn’t stopped us from releasing, so it was never a focus.
For my MMO project, I manually predict movement & skill effects. It’s just not built into Mirror.

I understand it’s important for some people.
But let’s solve scale first :slight_smile:

1 Like

Yeah, I understand. Do you feel like it’s something that you may add once you have scaling in the place you want it to be, even if that may be a few years in the future? I feel like it would be a good thing to keep in the back of your mind and then work on implementing once you feel like you’re happy with the state of current features and stability, and are ready to expand.

I’ve been working on CSP for my fork of mirror. It has all the main parts but I am working on improving and optimizing it before I release it (and probably make a mirror version)

1 Like

That would be awesome! I would love to use it once you release it.

Early CCU tests for Mirror II.

Goal is to compare with original Mirror to see scale & bandwidth improvements.
Keep in mind that this is not a real game. I’ll do a more realistic test for my own game in ~6 months.
Original Mirror results with same demo coming later this week.

Setup:

  • 1 x 16 vCPU server machine.
  • 6 x 8-16 vCPU client machines.
  • Unity 2021.3.9, IL2CPP.
  • Linux.
  • Threaded Transport (1 KCP thread).
  • Threaded Broadcaster (10 Broadcaster threads).
  • tickRate: 30 Hz
  • sendRate: 30 Hz
  • 10.000 monsters (red), moving randomly.
  • 0-1000 players (white), moving randomly.

Results:
Broadcaster avg. is at around 30% load, indicating that 3 threads would’ve been enough for 1000 connections.
Tick rate starts deviating from target 30 Hz at around 800 connections.
Quite happy that it passed with 0 issues.

0 connections:

400 connections:


1000 connections:


3 Likes

CCU Test Mirror classic vs. Mirror II
400 CCU Mirror classic:
bandwidth: 7.66 MB/s
cpu: 31.7 ms

400 CCU Mirror II:
bandwidth: 1,74 MB/s (4.4x lower)
cpu: 21.7ms (slows down at 800, allows 2x scale)

Summary: 4.4x lower bandwidth, 2x higher scale.
Quite happy with the results, considering it’s the first version and very first test :slight_smile:

1 Like

CCU Test Mirror II on dedicated Xeon E-2236 with 6 cores/ 12 threads @ 3.4 GHz (4.8 GHz).

Google Cloud vCPU server: 40.6 ms
Dedicated Xeon: 33.8ms
=> 20% faster.
=> almost manages to retain target tickRate of 30 Hz.

So if you were wondering: real dedicated CPUs can be ~20% faster than Google Cloud vCPUs :slight_smile:


2 Likes

Good to see the new update. This update should follow with new tutorials for new users.
Thank you.

Sure.
The next 1-2 weeks will be focused on documentation + performance tests.

1 Like

Hi, I need to have a centralised server which relays the game objects data and forwards to different devices, there is a way to do it (eg: installing the library server app on a remote server)?

I would like to have only two VR visors watch each other movements and audio chat between them.

check out the #epic transport in our discord.
free relay thanks to epic games :slight_smile:

1 Like

I updated Mirror to 2022.9.15 and now i’m getting errors. Four “type or namespace name” not found. This is with a fresh project too. Any solutions to this?

Please post the full stack trace + error here. That’s what they are made for :slight_smile:

Update: instead of releasing Mirror II this week, we will backport many of the improvements to Mirror.
There is too much value that can be added to all the existing projects, Mirror II can wait :slight_smile:
Afterwards do another round of CCU tests and re-evaluate.

Simplifying OnSerialize today, where previously it would need a bool return.
This was changed to void to a-void confusion and reduce branching for performance.
Also simplifies weaver generated code:

2 Likes

News: Snapshot Interpolated Timeline

Previously, NetworkTime and each**(!)** NetworkTransform would run on separate timelines.

Now, everything runs on the same NetworkClient timeline, thanks to our Snapshot Interpolation V2.
Less computations & complexity
All NetworkTransforms are now on the same time, instead of each being on their own time
NetworkTime is now implemented properly via Snapshot Interpolation. This is noticeably more accurate. There’s no more big jump in the first 1-3s.

This is one of those improvements which required months of research & testing, yet most of you won’t even notice it other than the fact that it just works :slight_smile:

Bandwidth optimizations, first round.

NetworkIdentity.Serialize bandwidth reduced from 1 byte per component index to (roughly) 1 bit per component :slight_smile:
https://github.com/vis2k/Mirror/pull/3228

before / after:

the removed byte per component:

1 Like