# ARCHIVE - SS3D Dev Post #2

{%youtube IH9Nv7UI1ps %}

## Networking Physics

"Physics would lag as hell" is what you see in about half of comments and posts around SS3D. I would be worried too, had i sync objects a traditional way, where server sends position and rotation on a regular basis and client interpolates state data. It's actually makes sense for game characters since they change their direction unpredictably, which makes it hard to extrapolate.

Inert physical objects, on other hand, don't have a will of their own - and if you kick the ball it would roll around until it hits the wall or friction does its thing.

Since each client supports own physical simulation we only need to be notified that ball was kicked and how strong it was kicked (and also keep in mind direction of airflow). From that input, we can reliably expect that resulting data on client would be pretty similar to real position of the object (calculated on server), even if it was extrapolated from a fairly small chunk of data.

Earlier for SS3D objects had their collisions off by default so you can stack things in piles like in SS13, but what's more important it makes their physical simulation unbelievably simple, which lower chances of desynchronization which, in turn, gives an oportunity to run more physical updates in a second (higher tickrate).

Therefore, you only need a very small bandwidth to synchronize data, and hundreds of bikehorns can fly around without taxing a server's perfomance (still there are some unsolved issues, but they aren't physics-related).

## UNet -> Lidgren

Unity networking (as of 2018) consists of two parts, low-level API NetworkTransport and high-level HLAPI that most amateur unity devs use. Both are fine, but by Unity tradition's HLAPI is very limited, and for SS3D I need a lot of non-standard stuff.

For example - each networked object has it's own ID like most multiplayer games do. But SS3D is pretty careful to sen *only* the stuff that a player character should see or hear, and all the effort would be in vain if a cheater could use Cheat Engine to dump all objects and figure their real identity by their ID. Such cheater could take a look on masked greyshirt, compare their ID with identificators of characters he previously met, rendering any attempts at stealth or concealment useless. To avoid this, server should override real ID with "fake" ones before sending out packets, which would keep any concealed information away from cheaters.

HLAPI is open-source, so I had no problems at first implementing such behavior. In time however, i learned that i swim against the current with this, and as a final straw some netcode i needed was actually embedded in closed-source parts of Unity.

I should finish moving to Lidgren on the next week so I hope I could have a first net test before the end of the month.

Thanks to Brukas, bman и Unevenmetalic Prankster for their models. They did a great job!