Harmony

Ideal networking for Unity Projects

Harmony is a framework for multiplayer networking in Unity, designed for high speed games build on Mirror. It is very early in development and will be the system used in Prodigy.

Features

-	-	-
Server Authoritative	No Client input delay	Prediction
Server Determinism	Low Bandwidth	Interpolation
Server Reconciliation	Low Cognitive Complexity	Rollback

Isn't that really hard?

Yes. Originally the concept for Harmony was much more robust with lockstep + determinism and all the fancies. This isn't really feasible for any team smaller than 5 working full time... We do want to publish at some point.

But, in terms of motivation and inspiration consider that Overwatch is an exceptional multiplayer experience. Blizzard has also made other fantastic multiplayer experiences that simply play well and work. For that reason we should take notes from them - check out reference 1 below (maybe watch at 0.5x too) for a fantastic explanation of how all of these features can be used to create the ideal experience for players while maintaining a deterministic server environment which can be replayed.

1. Overwatch Netcode (YouTube)

2. Glenn Fiedler - Deterministic Lockstep

3. Gabriel Gambetta - Fast paced multiplayer

4. Christian Tucker - Seamless fast paced multiplayer

5. Rollback Networking In INVERSUS

6. Game Networking Demystified

7. Client Side Prediction With Physics In Unity

So whats in the box?

Arguably, it's significantly easier to just sync transform data and some events than do all of the madness that the Overwatch team does and honestly, that might be the best, most practical option for you and your project. But we do want solid authority at the server and a comfortable client experience with low bandwidth and high response.

That's the fundamental goals we're looking to achieve. What's not in the box is replays, determinism, lockstep or rollback. Because that's too much work.

We're focusing on a server authority concept using rubber banding to correct clients. For example client says "I am located at this position, and these were my inputs this tick." and the server does something like "Ok, thanks, I'll sanitize these inputs and apply them, then make sure your location matches what I expect it to be. If I need to, I'll send you corrections."

So in that scenario the client is still in immediate control of his character for instant feedback and the server will validate inputs, then confirm that the client is in the right spot based on those inputs. If anything is wrong, the server will correct the client, and always send out where the server defines the player's position at.

Clients reconcile for lag locally, so any corrections on input would result in a rubber banding yank back to the correct position or state. In the end, server has authority and clients should see the most current state possible with similar prediction results - but not deterministic results.

Is this what I need?

Initially when you start building Multiplayer for the first time and create a naïve implementation you'll probably send position data and basic events like abilities. Sure it works and you feel all warm and fuzzy, but you soon realize that you have no way to enforce all players having the same experience or seeing the same thing. Pretty soon players are shooting in the entirely wrong direction and invisible enemies are killing you while you 'thought it was stuck on that wall'.

So that will lead you to looking for proper solutions to synchronizing clients. And the more you look, the more you'll realize that across the board - full server authority is going to come with caveats, real synchronization will require determinism + lockstep, and proper comfort will require interpolation + lag compensation.

So what do you do? Give up or ship a mediocre multiplayer experience, usually. Planning ahead will save you from this fate. Unless you have a system with determinism, lockstep, rollback and lag compensation in your pocket then you're going to look for more feasible solutions. Basically, yeah, this is probably what you need.

Don't let that happen to you!

If your game fits into a space where this architecture is useful then why not just use it? If you're making a Turn Based Card Game, well hey, maybe roll your own simpler solution because there's so few inputs it's easy to build something nice! But, we're designing for fast paced games with known solutions to common problems so you know you're getting a good foundation.

Pleasant adventures, - Lane