Das Problem das ihr da ansprecht kann durch Parallele Zustandsmaschinen (PSM) gelöst werden (siehe Gems 4, S. 591).
Zusammengefasst gibt es für jede Clientaktion einen Zustand, den der Spieler annehmen kann: Bsp: Wenn der Charakter sich vorwärts bewegen soll, dann wird er in jenen Zustand versetzt und schickt eine Anfrage an den Server den Spieler soundso in eben diesen Zustand zu versetzen. In der Zwischenzeit wartet der Client natürlich NICHT auf die Antwort des Servers, sondern setzt seinen Spieler in den gewünschten Zustand, und verfährt so, als wäre er gültig!
Auf der Serverseite bekommt dieser die Zustandsänderungsanfrage und überprüft ob der Zustandwechsel in Ordnung ist. Wenn ja, schickt er die Zustandsänderung an alle anderen Clients. Wenn nicht, korrigiert er den Zustand, und schickt die Änderung an alle Clients und die Korrektur an jenen der die Änderung verlangt hat.
Wenn nun der Client eine Korrektur erhält, wird er sofort in jenen Zustand versetzt, ohne lang zu überprüfen, ob das "legal" ist.
Somit sind alle PSM immer konsistent, und nur der Client, der eine ungültige Zustandsänderung vornehmen will (sei es weil er Cheater ist, oder wegen eines Lags!), erfährt eine Zurücksetzung seiner PSM!
Bezüglich der Physik, finde ich, sollte nur der Server die gültige Konfiguration kennen, und alle ÄNDERUNGEN (das heißt bei Änderung der Geschwindigkeit oder Winkelgeschwindigkeit) an die Clients senden. Der Rest der Physik wird auf den Clients (aus v und w (omega)) berechnet. Somit müsste alles immer konsistent bleiben, sofern man den Änderungen einen Zeitstempel verpasst, damit der Client dementsprechend reagieren kann, und damit die Position RICHTIG aktualisiert (Positionsrekonstruktion!!)! Bei nicht allzugroßen Änderungen dürfte es dann keine unschönen Zurücksetzungen mehr geben. Kollisionserkennung und Response werden zwar auch auf dem Client berechnet, aber nur als VORHERSAGEN verwendet. Die wirklichen Daten bekommt dieser dann vom Server. (Bei Kollisionen kann es sein, dass der Server zusätzlich zu v und w auch ncoh die absolute Ausrichtung und Position senden muss, da es möglicherweise schwierig werden könnte die richtige Position zu rekonstruieren (wegen der verwendeten Deltafunktion bei der Collisionresponse! (Unstetigkeit!))