4 ms·

Cosmoteer relies on deterministic floating point calculations to keep the multiplayer simulation in sync between computers. Cosmoteer is also written in C#/.NET

Cosmoteer relies on deterministic floating point calculations to keep the multiplayer simulation in sync between computers. Cosmoteer is also written in C#/.NET, which uses SSE instructions for 64-bit and FPU instructions for 32-bit, which can produce slightly different results.

gridspy 7y ago
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?
- cobalt 7y ago
  sure, if you want to pay them to do that
  - gridspy 7y ago
    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 7y ago
      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 7y ago
        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 https://data.firefox.com/dashboard/hardware
        Quarr 7y ago
        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-Software-Survey-Welcome-to-Steam https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
        TheRealPomax 7y ago
        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 7y ago
        This is only true if you think that the Firefox demographic is skewed towards 32 bit computers.
        TheRealPomax 7y ago
        other way around: it assumes most non-firefox users are on 64 bit, which is a pretty reasonable assumption given Apple's hard push for 64 bit (so that's the OSX-ers covered) and Chrome's "we've made finding the 32 bit installer _really hard_ because we don't want you to use it" move. I'm sure there are some 32 bit users in both segments, but far less than you'll find in firefox land.
      - romwell 7y ago
        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 :)
- waltdestler 7y ago
  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 7y ago
    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).
jtolmar 7y ago
Try adding an occasional pass that rounds or truncates all your floats (maybe once a frame, maybe less). It's not really "supposed" to work in any bulletproof way, but for a given game there's usually a reasonable rounding factor that'll fix things faster than floats diverge.
magicalhippo 7y ago
Not all instructions are required by IEEE-758 to return the exact same result between platforms. Though I guess the errors might be too small to notice for most object in this game.

gridspy 7y ago

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?

cobalt 7y ago
sure, if you want to pay them to do that
- gridspy 7y ago
  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 7y ago
    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 7y ago
      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 https://data.firefox.com/dashboard/hardware
      - Quarr 7y ago
        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-Software-Survey-Welcome-to-Steam https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
      - TheRealPomax 7y ago
        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 7y ago
        This is only true if you think that the Firefox demographic is skewed towards 32 bit computers.
        TheRealPomax 7y ago
        other way around: it assumes most non-firefox users are on 64 bit, which is a pretty reasonable assumption given Apple's hard push for 64 bit (so that's the OSX-ers covered) and Chrome's "we've made finding the 32 bit installer _really hard_ because we don't want you to use it" move. I'm sure there are some 32 bit users in both segments, but far less than you'll find in firefox land.
    - romwell 7y ago
      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 :)
waltdestler 7y ago
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 7y ago
  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).

jtolmar 7y ago

Try adding an occasional pass that rounds or truncates all your floats (maybe once a frame, maybe less). It's not really "supposed" to work in any bulletproof way, but for a given game there's usually a reasonable rounding factor that'll fix things faster than floats diverge.

magicalhippo 7y ago

Not all instructions are required by IEEE-758 to return the exact same result between platforms. Though I guess the errors might be too small to notice for most object in this game.