Question NetworkTransform and client-side prediction

In the latest development version of MLAPI, there are NetworkTransforms (server-authoritative) and ClientNetworkTransforms (client-authoritative). However, I'd like to be able to update the player position authoritatively on either the server or the owning client, in order to do client-side prediction and server reconciliation (to deal with lag).

What is the correct way to do this in MLAPI? Are there other transform components that do work for this? If I have the server always move the player, the movement will feel sluggish to the player, but if I always have the owning player do it then I'm sensitive to cheating (and also get issues with e.g. spawning).

 

You would need to write your own component if you want client-side prediction and lag compensation.

You are right about latency and cheating issues with the two models which we provide. Client side prediction solves these issues but provides other problems to deal with. Implementing it is non trivial, for instance the process of reconciliation (correcting a mis-predicted player) is very complex and part of it is re-simulating multiple gameplay ticks. We will be looking into providing ways to do all of that in the future.

 

Thanks for your quick reply! Any recommendations for how to do this in the meantime? Use ClientNetworkTransforms and have the server send corrections via ClientRpc when necessary...?

 

I would use either NetworkVariable or custom messages and build my own from scratch. I can't think of a way to retrofit the exiting NetworkTransforms into a client side prediction model.

 

The Client-side Prediction with Reconciliation feature is still Under Consideration on the Multiplayer Networking Roadmap, I suggest voting for it there if you are interested. I think the feature is Critical, as I cannot imagine any serious attempt at a real-time online multiplayer game (e.g. a hero shooter) without including this as a core feature.

Implementing it from scratch within Unity is just not feasible for most developers, and implementing it properly requires substantial code generation, just look at Unity.Netcode.Editor.CodeGen and the extensive code generation that

com.unity.netcode.gameobjects

is using. Unfortunately, Unity offers no public documentation for code generation, and

Unity.CompilationPipeline

is only accessible to

Unity.*.CodeGen

assemblies, signaling that external developers are not even welcome to take this path. Mirror takes this path anyway, and you should take a look at the madness taking place in Mirror/Assets/Mirror/Editor/Weaver to get a glimpse of the complexity and difficulty involved in creating a custom networking solution for Unity.

If Client-side Prediction with Reconciliation is not going to be implemented by Unity, I'd request that Unity provide better tooling and support, especially around code generation, for developers to create their own networking solutions. Doing so would make Unity a more viable choice for teams developing serious real-time online multiplayer games.

 

You're right, it's infeasible to do this from scratch for indies. Thanks for pointing to the roadmap, I voted for it there. I'm writing a 3D shooter as well, so it's absolutely critical.

 

Good gravy, Unity aren't making this easy. So I've been trying to use Netcode / MLAPI / Whatever state this is in and someone decided that ClientNetworkTransform shouldn't be installed with Netcode by default, but hidden in the "samples" in the package manager...

All I wanted to do was to update players in realtime with joypad/keyboard input and not making RPCs...

This thread triggered me to look for the right term and I found it buried in one particular page.

 

You might be able combat this by having the server validate the movement on its end AFTER it happens, as to not introduce lag.
If the movement is feasible from the server's point of view, then all good, if not then snap the player back to where he's supposed to be, and possibly trigger some anti-cheat check.

This way if someone is speed hacking, flying or teleporting around using cheats, you'll be able to detect it without sacrificing the responsiveness of movement.

I wouldn't worry too much about cheating, you can't really stop it, aimbots, wallhacks, etc. will always be there. Especially if you are indie, don't waste too much time trying to beat cheating, even AAA studios can't do it.

 

I strongly disagree. "In any competitive game, a cheating player isn’t just making the experience better for himself, he’s also making the experience worse for the other players" (Gabriel Gambetta), and it can absolutely destroy your game. Any competitive multiplayer game without server authority has practically no chance of succeeding. And for many game types, the best possible server-authoritative experience relies on using client-side prediction. Until Unity adds native support, indie teams using Unity will continue to experience a huge barrier to entry for entire multiplayer genres.

Aimbotting (and normal botting) are a special case because they are unaffected by server authority, and are out of scope of the issue here.

 

I'm fully aware of the negative effects cheats have on games, what I am trying to say is that for an indie team with limited resources, too much effort spent on anti-cheat might very well be wasted effort that could have been spent elsewhere, especially if you are building a shooter which is a genre that is very cheat prone.
Don't get me wrong, I'm not saying don't do anything. Do what you can, but I wouldn't spend too much time on it (if you are indie) at the expense of other parts in your game. When your game reaches any kind of large audience, there will be cheats, always.

You don't have to take my word for it, look at AAA game studios and how cheats plague their titles, from COD, Battlefield, CSGO, Apex, etc.
And these are triple A studios with large teams and resources available to them.
Some even have dedicated anti-cheat teams that play cat and mouse with cheaters, and cheaters are often ahead.

We can't simply dismiss them because they cannot be server authoritative, they will ruin your game. What would be the point of spending too much time on things you can make server authoritative if wide spread cheats like this will easily ruin the game... You would have gained little, your game will still be ruined by cheats.
Like I said, do what you can, but as an indie with limited time and resources, often times your efforts could be better spent elsewhere.

If you are building a shooter on PC, you have to accept that cheats will come along with it when it reaches a large enough player base. That's the sad truth.

Just to recap I agree with making what you can server authoritative, I'm just saying not to waste too much time on combating cheats as an indie dev with limited time and resources, as for a shooter there will always be cheats unaffected by server authority that can render your efforts futile and ruin the game regardless.

A possible alternative is letting your community host servers and handle cheaters, much like the old days of CS and BF.
There are alternatives but perhaps not for indie studios, like implementing "Prime Accounts" ala CSGO to help (and I say help because you can't stop them) against cheaters easily coming back, by putting an XP wall (time, rather effective) against them, as well as tying the account to a phone number (which is less effective).

 

All four of your example games use client-side prediction, and all four would have been unsuccessful without it.

Yes, we can dismiss them, because this is a thread on client-side prediction, and as I said aimbots and such are out of the scope of this discussion. I think your message that "indies shouldn't worry about client-side prediction because of the existence of aimbots" is ridiculous and I responded because I want the message to Unity to be crystal clear: indie teams do want this feature.

 

If Client-prediction and server reconciliation are what you are after.. don't wait on Unity.
My suggestions, use Photon's Fusion. It is AAA by design, being utilized by top studios, AND incredibly accessible to indies once you understand the fundamentals at play. Plenty of free samples as well demonstrating various features.. and no, I do not work for Photon.

 

How is it cost wise? Can you host your own server? Do you pay for server hosting or the sdk? How is licensing?

 

Without getting too off topic you pay for CCU, which they say translates roughly to:

DAU = 20x CCU and MAU = 20x DAU

1,000CCU >> 20k DAU >> 400k MAU
5,000CCU >> 100k DAU >> 2m MAU

IMO when you consider the fact at 100 CCU (one-time yearly of $95) you're normally at 2k dau, 40k mau... which means you need 50k+ copies downloaded/sold.. and then after that it's their more reasonable production CCU at $125/500CCU a month.

Fusion specifically can't be self hosted, but you are free to host your dedicated game servers anywhere you want.

To me that works the cost out to be a non-issue considering their offerings, you're paying for their cloud usage as well as their engineering point blank- their delta compression in use is industry leading, you won't find a better option for fast paced production ready multiplayer IMO.

 

Fishnet has CSP for free. Might want to check that out.

 

Is there any progress? So there is no point in making a multiplayer game that includes physics without this.