[gridspy]

Oh no!

Perhaps you need to either switch to a deterministic physics approach with fixed point math or do some research on float determinism (which is much harder).

Or, give up on lockstep and move to client-server replication with prediction on your own ships?

[waltdestler]

I've looked into all of those things in the past:

- 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.

[gridspy]

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).

[cobalt]

sure, if you want to pay them to do that

[gridspy]

Hey, it is just what I am planning to do on my own game. Supposed to be kind advice. Surely they don't want to split their user-base?

[TheRealPomax]

Is there anyone left on 32 bit at this point in time on their daily driver? Windows, Linux, OSX, they've all been 64 bit for many iterations now.

[cpeterso]

About 24% of Firefox users still run a 32-bit OS, though gamers probably have newer hardware and software than the average Firefox user. See "Browsers by Architecture" in the Firefox Hardware Report for a graph over time:

https://data.firefox.com/dashboard/hardware

[Quarr]

The Steam hardware survey suggests fewer than 2% of users are on non-64-bit OSes. There are more Mac users (~3%) than 32 bit users.

https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...

[TheRealPomax]

As depressing as it is to say this: Firefox's marketshare is so low that we really need the Chrome numbers here. 24% of a <10% market share means "quite likely around 2.4% globally". That's basically a number that says "safe to entirely ignore in terms of userbase support" =/

[gridspy]

This is only true if you think that the Firefox demographic is skewed towards 32 bit computers.

[romwell]

I do have a 32-bit device (Asus T100 netbook/transformer) that I use regularly enough for it to be a 'daily driver', especially when I travel.

But I'd be OK with this limitation :)