I am trying to make a fast paced online shooter using Unity's physics. Help

So I really want to make a 3d online shooter with a rigidbody controller. I don't use Photon or UNet, instead, I use custom-built package management & internet communication. Link to the tutorial I followed:

Since it's basically my first experience with networking I wanted to ask for some advice. For example, I want to implement a server-authoritative game with a tickrate system (very similar to Valve's netcode: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking). But I also need to do physics movement. So, is it okay if I send out server movement data in FixedUpdate() with a timestep of 0.015 seconds? Or is it better to have some kind of timestep variable and send out data in Update()? Also, right now, the script that takes player input and applies forces to player rigidbodies and sends out player positions back to the client(s) is attached to individual players, but I feel that this is not the best way to do that. In articles like this: http://www.codersblock.org/blog/client-side-prediction-in-unity-2018 the author, when doing input prediction, says that after receiving a server snapshot, he has to re-simulate the newer movements. How? Is he applying the forces again? I understand everything until the point when he stores input. (By the way, I know this article exists (In fact, I read it a lot of times) https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html)

Here, I uploaded my client and server to GitHub: https://github.com/spicymuffin/Backup-multiplayer-before-input-prediction

Help is appreciated. Thanks in advance!

 

One problem when writing your own network API is you're largely on your own for these kinds of questions.

On physics, Unity has a new physics implementation they are designing in house, currently in preview, which implements physics roll back which should be useful for rolling back physics state so they can be replayed with updated data from the server (I haven't used it).

https://docs.unity3d.com/Packages/com.unity.physics@0.3/manual/design.html

On the networking tutorial, it says it is a TCP tutorial. TCP is not ideal for a fast paced shooter. UDP is a better choice, where you implement your own reliable message system for packets you need the client to receive, but don't resend any lost packets which are too outdated to be useful if resent (probably the majority of your movement related packets).

With TCP for every lost packet you block the entire network stream until the entire window is resent by the server and received by the client, not matter if there is updated information stuck waiting to be sent.