Mirror Networking for UCC Add-on

Matt

Member
Please note that this add-on is currently under development and is not available for purchase. More details including the pricing and any closed alpha/beta testing will come in the near future. This is mainly an announcement and discussion thread - any progress will be posted as milestones.

To help keep the PUN Network announcement thread clear of Mirror discussion, this is the thread for the UCC Mirror Add-On.

The idea of my Add-on is to make it as transparent as possible so you don't have to get your hands dirty having to write the network code yourself. Basically, the features you see in the PUN integration should be in my Mirror add-on.

Let's get started!

Is Mirror better than PUN?
Both Mirror and PUN do the same thing - network your game. However, it's how the network system interacts with your code and scene that matters.

Photon Networking
Please note that my PUN knowledge might be very limited and/or incorrect. Do your own research about PUN before taking my words seriously!

PUN is based around a Peer-to-Peer Client Authoritative environment, where one client in a room behaves as a HostClient (Game Host and Client in one instance) while everyone else are connect to the host in client-only mode. The host client and standard client(s) all chat to each other each time something of interest happens.

This sort of communication is much like console P2P games (see Modern Warfare and Modern Warfare 2 on PlayStation/Xbox). As such these messages bounce back and forth between all clients all at the same time.

Photon is designed to get you running FAST... which means it's also based on a subscription model. You pay for the CCU and Messages Per Second. Your game gets relayed through Photon's Cloud services so players can be on a really bad connection (Australian internet) and Photon still has your back. It's also ideal for games that need quick and dirty network prototypes up and running without the fuss of server instances etc.

However, for some games like shooters, unless you are willing to spend big dollars on anti-cheat solutions, it makes sense to forfeit PUN for a server authoritative solution.

For example, you shoot Sarah on your screen for 5 damage, and your client will say to everyone else in the room, "Hey I shot Sarah for 5 health". They all reply with acknowledgements and you see Sarah's health bar 5 points less.

Now Justin comes in with his overpowered RPG launcher and fires it at you for 200 damage. You just got swiss cheesed, so your client says "Haha, you got me, I want to respawn now". Again, the host and everyone else in the room say "That's cool" and you respawn.

Another example is you're looking at a explosive crate. And thinking it's a cool idea to play with that. Well, your client is busy saying "Hey I'm looking at the crate at XYZ, I'm also running interact ability" to everyone else. Everyone else in the room knows you're looking and playing with explosives.

Techy details:

PUN uses a CCU system which 1 connected client is 1 CCU. CCU stands for Concurrent Users. Each subscription tier has a CCU limit and Messages limit.

The benefit of this model is that it's easier as you have a fixed cost every month to run your game online, and it's faster to deploy. Exit Games also have cloud relays implemented so that you and your mates can connect anywhere when you have a stable internet connection.

The downside to PUN is that it seems that the Game Server host has to be Windows-only (citation needed) and some people don't like this subscription based system. PUN provides Networking as a Service (NaaS) and Exit Games could boot you off their services at any time.

There's also the problem of room security - unless you're using encryption, there's been hackers that breach the protocol layer of the Photon networking layer and can take control of rooms. For example, we had a developer come from PUN to Mirror because he had to bribe a hacker to stop ruining his online experience since the hacker would connect, take control of the room and randomly spam "kill player" packets to everyone for easy wins. This could be avoided by using encryption, for example.

Mirror Networking
Mirror started out as HLAPI Community Edition. As someone who used it in the past for TPC 1.3.x networking, it was a godsend over Unity's buggy UNET implementation. Mind you, we are not talking about the new UNET that Unity is taking forever to implement with their "Multiplay" services - we're talking about the old UNET that has been around since Unity 5.

Mirror is designed for server authoritative networking in mind. Basically, the server instance - be it a Dedicated Server or Host Client instance - barks the orders and the clients must acknowledge them or they'll be booted off the server. Clients use Commands and the Server uses custom Messages or RPCs (Remote Procedure Calls) to tell Clients what to do. If a client tries to do something that requires server authority like set someone else's health on an object they do not own, then they are denied and an error is thrown.

That said, the Mirror Networking API is completely open source apart from some paid add-ons that enhance things like 1000+ CCU. The benefit of being open source is that you can easily look at the code when you encounter a bug and get an idea of the code path your code is going through.

This makes it possible to use your own infrastructure in the form of cheap VPS from providers like Linode, Vultr, etc to run your online game servers, be it Windows, Mac or Linux. Or if you have the cash, you can rent a dedicated server with a full remote access solution and have real performance like how AAAs run the show. I have a in-house test server in Sydney that has this setup and it's sweet.

The downside is you need to know how to maintain a Windows/Linux based server and also open ports on the firewall. Linux based VPSes are cheaper and more secure to run, but you have to learn the Linux way of running binaries while Windows is point and click. Once that's sorted you're smooth sailing.

NOTE: Both systems can run in client authoritative modes, however Photon is designed around it exclusively. Mirror is focused on server authoritative, but some components can run in client authoritative mode.

Which one is right for me?
That's the ultimate question. You need to do your own research and figure this answer out, but here's a few dot points:
  • Define your game genre. Fast paced games can be developed with Mirror or Photon. However, if you're going for a party game like Mario Party, then Photon will be a better fit. For a server tick-based system that has the final say as to what happened, then Mirror is the way to go.
  • Do you need NAT punch through and relays? Photon ticks the box. Mirror requires additional setup, unfortunately.
  • Do you want to be able to use a TCP and WebSockets multiplexing system at the same time? Mirror can do that.
  • Are you planning to release for console (PlayStation/Nintendo Switch/Xbox)? Photon has been battle tested on those platforms, however due to limited resource power, Mirror has not been tested on consoles. That doesn't mean you can't use it, it could encounter some weird bugs that need to be reported.
By all means, try the Photon add-on. It might set you back a few tenners, but if you find it's not suitable for your game, you can always try this one.
 
Last edited:
What will I need to use this Add-on?
Mirror works from 2018.3.6 onwards up to 2019.2 Stable at time of writing this. The Mirror team and I do not support Alpha or Beta versions of Unity with Mirror. It may or may not work. If it does, then good, but if you have a bug, you will need to replicate it on a stable version of Unity.

I see a worrying trend of new developers updating to every major dot point in a Unity release and this is a bad idea. Or they go for the latest alpha/beta and expect it all to work from the get-go.

If you are going to be serious about your network game, you make sure you choose a version that will work and keep using that version until you face a bug that forces you to upgrade. You do not want to upgrade every dot release and then find a bug in that release has just completely killed your project beyond recovery.

Do not simply just upgrade because "oooh, shiny new features" - majority of the time you do not need the upgrade unless you are experiencing a bug that has been fixed. Professional developers don't upgrade versions on a dime. With that out the way, here's the dependency list:
I will not be bundling Mirror with the add-on, you will have to install it as a dependency.

What about client prediction and server replay?
This topic is very advanced and will eventually be included in a later milestone demo and/or post-addon launch. Right now, the goal is to use the basic Mirror API to get the controller networked and moving around, then going up the chain.

Does this include features like Team Deathmatch, Battle Royale, etc etc?
No, you will simply be getting a base network implementation that you can extend from there, much like the PUN implementation. You will not be getting a full networked game template, where you can just throw some characters into a scene, click a button and a fully functional networked team deathmatch implementation is yours.

The demo scene will most likely include a free for all barebones mode that allows you to get a feel for the add-on.

Can I use this as well as the Photon Networking add-on at the same time?
Trying to mix and match network systems never goes well and you will get breakage. You either choose PUN or Mirror based on your needs.

Will you post a demo of the add-on?
I am undecided as of yet if I will release a network demo due to code security. If I do release a add-on demo, it will most likely be a playable demo of my studio's game that's been in the works for quite a while. I might even do a closed alpha/beta round of testing.

Alright, this post will be updated as time goes on. Ask any questions you might have. Cheers!
 
Last edited:
Sounds super awesome! I'm really looking forward to this one.
I have a couple of questions now.

1. How soon do you think we can have something to test, after PUN2 releases?

2. Will it support join-game-in-progress?

3. Will it come with some example such as Lobby and a sample game mode, e.g., basic TDM, or Free-For-All? I know you mentioned it will not come with full TDM but some example from the lobby to a game will help.

Thanks.
 
Sounds super awesome! I'm really looking forward to this one.
I have a couple of questions now.

1. How soon do you think we can have something to test, after PUN2 releases?
Probably a few weeks. I am currently doing contract work for other developers so it depends on how that goes and what time slots my real life IT consultation clients consume.

I have a private Notion task board that has 3 milestones. We're going to piecemeal the development of this add-on (read: taking it in baby steps) so it isn't overwhelmingly difficult to implement, but I will be updating here as soon as we have progress. As milestones come along, I will most likely be releasing playable Mirror network demos.

2. Will it support join-game-in-progress?
Mirror by design will bootstrap any client that joins in the middle of a match, but it's up to you to implement such functionality if players should only spawn when a game is not currently in-play. But the answer to this question is yes, you should be able to join in the middle of a round and start fragging away.

3. Will it come with some example such as Lobby and a sample game mode, e.g., basic TDM, or Free-For-All? I know you mentioned it will not come with full TDM but some example from the lobby to a game will help.
I'll most likely have some sort of Demo mode, probably free for all with a crude scoreboard tracking all thrills and spills. I don't want to include too much gameplay in my add-on as it's supposed to be a basis for your own networked gameplay implementation... although I'm half expecting someone to asset flip.
 
Thank you very much. I'm happy to hear the answers. It really makes me exciting. I'll try to do my best to test once it's available.
Cheers!
 
I should clarify that I will most likely have a Milestone demo a few weeks after the PUN add-on releases. This first demo will most likely be a proof of concept and just have the core mechanics (ie the interaction room like in the PUN add-on). I won't be doing closed alpha/beta of the add-on until later in it's development.
 
Hi will we need the full UCC product or will it work with UFPS2?
I'm developing it with UCC in mind, when I get to release stage I will probably try to get it working with UFPS2 and friends. Since it's all the same code base, it should work - probably need to make some definitions to toggle things in the code.
 
1473

Update time!

Sorry for the late response. Been very busy hammering away with the add-on and IRL stuff.

We've spotted a bug that affects the UCC Network Characters causing an infinite loop in some of the INetworkCharacter hooks. So we've had to stub some of those; but the good news is that we actually have network players spawning over the network. I am working with Justin to debug that further and will probably be submitting patches upstream for inclusion in future versions of UCC and/or Multiplayer.

We are aiming to get movement and other essentials done first for Milestone 1. Due to the complexity of UCC, it seems that our "quick and dirty" idea of using the improved NetworkTransform does not work correctly. Players will move on the local client, but the movement is like if you were stuck in a washing machine.

Player heads do synchronize correctly if you are watching the player on the server, unfortunately for the client however they have a serious case of twitching. They should go see medical attention.

Server rewinding and replay for hit detection will be coming in later milestones, right now the goal is to have a Mirror equivalent of what you get in the PUN add-on. From there, the "what sets this add-on apart from PUN" features will be slowly included over time.

This is all rough at the moment with no ETA of an alpha demo.
 
I should also mention that the minimum version of Unity required for this add-on will be 2018.3.6; older versions of Unity are NOT supported with Mirror. 2018.4 is the recommended minimum version of Unity for the UCC Mirror Add-on.

Any alpha or beta versions of Unity WILL NOT be supported as this is also the policy of Mirror development team.


So, in short: 2018.4 and 2019.1 will be the network target Unity versions.
 
Haha, it looks good literally. ^^ I think Mirror is the only viable options for the commercial networking solution right now and I really appreciate for your hard work for the community. Please keep us in the know.
Cheers!

Oh BTW, do you know anything about split-screen multiplayer support? at least for the development? I can't imagine building the client every time I tweak something and it's going to be the biggest bottlenecks for the multiplayer development. I remember Justin mentioned it's already in there with some material related issues but I'm not sure if there has been any progress.
 
This was one feature that old UNet had that we ditched in Mirror. The name of that is more so couch co-op, where you'd have 2 player objects per connection. Unfortunately, Unity Tech's implementation was half-assed and it only partially worked, so it was prime meat for the butcher's knife.

In theory it would be possible, however Mirror uses one player object per connection. So it would be possible in theory but would require some clever work around by using a master player object with two 2 pawns (Unreal 4's term of networked players).

To take away some of the pain, consider using the Unity Local Cache Server. That will speed your builds up ten-fold. A teammate and I were talking about it last meeting and it really accelerated imports and such. Since everything gets cached, the Unity editor just asks for the cached copies and slaps them together.

Alternatively, and this is going to sound weird, but build a big network scene that you use for testing your network interactions and code. Have all the things you want in that scene, be it hills, terrain, items, weapons, etc. That way you can test in a control environment and save build times.
 
That's an interesting story. I didn't know that UNet had that feature even though it's a butt naked solution. ^^
At least they thought that it's a useful feature.

However, having one connection for all players from the split-screen seems like you are asking for troubles. You will need quite a bit of special codes.
I thought in order to support split-screen multiplayer properly, you will need one connection for each split-screen player to make it more reliable.
This way, from each players point of view, you are running the exact same code except for managing split-screens that are not related to networks.

Anyway, I think the first step to support split-screen multiplayer is to support split-screen local(no network involved) multiplayer.
It's a useful feature but I'm not sure if's in the roadmap or not.

cheers!
 
I believe TPC1 had Couch Co-Op but I don't know what that did (I did see "Local Co-Op Player" option in the inspector). Maybe stops the player from trying to attach to the camera? Never looked deeper than that into that logic
 
Reading about recommended Unity version for Mirror gives me a little concern.
It's not released but there is one feature I'm really dying for in 2019.3, i.e., Enter-to-PlayMode without assembly reload.
My current project takes about 15 seconds to enter the PlayMode and this feature will allow entering in about 2 or 3 seconds or less.
This is a huge game-changer and everyone can benefit immediately.
Please check it out if you haven't already.

Having said that, if Mirror is locked to 2018.4 (hope not) I might have a problem moving to 2019.3 when it's release.
I understand about Unity being a fluke but it seems like Mirror's support for the latest released version is not one the top priority.
 
It may be supported when the said version exits alpha/beta. Same with 2019.2. There's simply too many moving parts and the Mirror Dev Team is a small group of developers, excluding all the community members that have contributed code and fixes, etc. We simply do not have the man power to have us working on the core, testing on 2018.3/2018.4/2019.1 and then supporting alpha and beta versions. We've got some devs using 2018.2 with Mirror because they are working with the PS4 development kit that uses that said version but in return, we cannot support them and they are on their own since we can only support 2018.3.6 onwards.

You can use Mirror on 2019.1 without major problems. Mirror is focused on stability, and if you don't want to use it because it's not compatible with your version of Unity then give it some time and it'll (Mirror) will most likely support it.

Unity's problem is that all the new features are always in the newer versions of Unity and never backported to the LTS versions. They have the power to make backports happen but they are instead interested in trying to catch up to the other "big name" engines.

There is a chance that Mirror will work without problems on 2019.2/2019.3. But if it breaks in half, then you're better off filing a GitHub support ticket with the stack trace and allow us to implement said version support.
 
Thanks for the explanation. I understand that everything is uncertain, I just wanted to know Mirror developers are not so rigid about supporting the latest version. Taking advantage of the new Enter-to-PlayMode will take a while even after it's released and I hope we can iron-out Mirror during that time.
Cheers!
 
Small update:

Slowly but surely. We're currently investigating a few issues with things not being sent over the network and severe twitching.

No ETAs as of yet, but I am aiming to get a good chunk of progress done this week.
 
Small update:

You are now able to push rigidbodies over the network. If you've seen the discord you'd have seen me playing soccer with explosive crates.

Next up on the list is fixing network animations and incorporating a new movement synchronization engine.
 
Update:

After some debugging, we found that one of our issues stemmed from the fact a component was stubbed (as in, a empty placeholder version). Oops!

We're working on a much improved system for synchronizing the players across the network - aiming to provide a better network movement implementation. This system will be the basis for server authoritative movement in the near future.

We're also going to be replacing the almost-nude test female character with something more appropriate; maybe even bringing in Nolan from Opsive's Demo scene once we get up and running with the core components.
 
Top