- Making C#/.NET floating point deterministic across x86/x64 is not possible, there's no way for force the JIT to output a specific instruction set.
- Client/server with prediction works for games that have relatively low numbers of objects that need to be synced (i.e. most first-person shooters). It doesn't work well when a game has thousands (or in Cosmoteer's case, tens of thousands) of individual objects that need to be synced, the bandwidth and CPU costs of keeping those synced is astronomical. Originally that's how Cosmoteer's multiplayer used to work, and it was a disaster, plus the code to keep everything in sync was insanely complicated.
- Switching to fixed-point is the only remotely-viable option you suggest, and I've strongly considered it in the past. But it'd be a huge amount of work to port all of the floating-point code to fixed-point, and there would likely be a significant performance loss in doing so. Since 32-bit users are only about 2% of all Steam users, I think it's not worth doing.
Based on playing your game, it seems you need to sync:
4 bits per object - Reload / capacity status (This is mostly visual for other player's ships)
2 bits - number of people manning module
Damage (4 bit?)
Location (x y), current orders (move, direction, orbit) per Ship
For bullets:
Bullet / missile location, velocity / goal.
Most ships have 20-200 modules? So one packet (~400 bytes) per ship? Plus a "Ship came into visual range" packet with ship layout data.
All the little people, treat them like a client-side effect. Completely predicted for other people's ships. Run the same logic on both based on the network synced capacity status.
Either change your model to predict X time to move resource from A .. B (carried by a person) or have each client claim time spent. It is highly unlikely that a player will observe another player's ship and say "But that person just carried X to Y but the levels didn't move!" So it's a case of each client saying "My ship's module's levels (based on crew) are currently XYZ" and the server / other client going "Hmmm, yep, seems feasible. OK"
It can be done, it's not impossible. Just work - it's a design choice.
I would argue that as long as the ship (as a whole) is controllable but still fully customizable people won't worry about faithful sync of other player's ships. And they will only care about accurate people in the ONE ship they are currently editing (fully zoomed in, no roof).
- Making C#/.NET floating point deterministic across x86/x64 is not possible, there's no way for force the JIT to output a specific instruction set.
- Client/server with prediction works for games that have relatively low numbers of objects that need to be synced (i.e. most first-person shooters). It doesn't work well when a game has thousands (or in Cosmoteer's case, tens of thousands) of individual objects that need to be synced, the bandwidth and CPU costs of keeping those synced is astronomical. Originally that's how Cosmoteer's multiplayer used to work, and it was a disaster, plus the code to keep everything in sync was insanely complicated.
- Switching to fixed-point is the only remotely-viable option you suggest, and I've strongly considered it in the past. But it'd be a huge amount of work to port all of the floating-point code to fixed-point, and there would likely be a significant performance loss in doing so. Since 32-bit users are only about 2% of all Steam users, I think it's not worth doing.