4 ms·

Awesome, I just upgraded our project! We're using wasmer in a browser-based multiplayer game in order to get cross-platform floating point determinism so we can

Awesome, I just upgraded our project! We're using wasmer in a browser-based multiplayer game in order to get cross-platform floating point determinism so we can send only input packets over the wire confidently without worrying about state drift. The client and server run the exact same wasm bundle instead of just being compiled from the same source, and the wasm spec guarantees that as long as you don't touch NaN and stick to one thread, you'll get the same results in any runtime [1]. [1] https://github.com/WebAssembly/design/blob/main/Nondeterminism.md https://github.com/WebAssembly/design/blob/main/Nondetermini...

jacobolus 5y ago
> as long as you don't touch NaN Note: this says NaNs one place will be NaNs everywhere, just the precise choice of NaN bit pattern is unspecified. So there is no issue “touching NaN”; the issue would be trying to pack some additional information into the fraction bits of the NaN, and expecting every implementation to treat it the same.
- cylon13 5y ago
  Yeah, that's a good point actually.
wiqar 5y ago
Hi, I'm Wiqar, product manager for Wasmer. We would love to hear more about your application and use case. Is the app in production?
- cylon13 5y ago
  The game using Wasmer is currently fairly early in development, but we have a few games in production built using various technologies, with the most recent one that I worked on done entirely in typescript. Both this previous game and the upcoming game are fast-paced action games. As much as I enjoy typescript, there are lots of annoying things that crop up in game dev in particular with regards to memory management, such as needing to pool instances of small classes, etc, so I figured it's time to switch to rust+wasm since the ecosystem seems mature enough now for it and Rust is a joy to program in. The architecture of the games are such that the main game logic runs both on the client and the server. The server runs the logic to provide the authoritative game state and send it out to all the clients, and the clients run the logic to predict where they're going to be immediately after you press an input to compensate for the network latency. Since the client is predicting what will happen using the same code paths, the game logic need to be completely deterministic so that it desynchronizes from the server as little as possible. With the TS/JS game we essentially just hope that running the same JS bundle in node and any client browser produces the same results for all the collision/gameplay math, and it seems to luckily not cause us any problems. For the game in rust though, compiled and optimized native rust floating point math would drift from our client webassembly builds surprisingly quickly, so we decided to pack all the shared logic in to a wasm bundle that gets loaded on both the server and the client, and we're using Wasmer to do that :) The Wasmer API is super ergonomic and it's been a pleasure to work with. I think the only thing that would make our lives better that I can think of is being able to ignore imports and have them auto-bind to noop functions or functions that immediately return zero in the case of non-void imports. Since we're using the same wasm bundle for the client and server, there's a bunch of client-only rendering bindings that we just ignore and never call from the server-only and shared wasm code in the bundle, and currently we're using a hacky script that uses wasm-objdump to generate a rust module with a bunch of noops in imports!{}.
astlouis44 5y ago
Interested in hearing more about your browser game. Another dev and I are working on a next gen HTML5 gaming platform using WebGL/WASM, and we're looking to back developers creating interesting titles. We provide access to our suite of devtools for optimizingprojects for the browser, and deploying on our platform. Link to our Discord if you're interested in discussing this further: https://discord.gg/zUSZ3T8 https://discord.gg/zUSZ3T8

jacobolus 5y ago

> as long as you don't touch NaN Note: this says NaNs one place will be NaNs everywhere, just the precise choice of NaN bit pattern is unspecified. So there is no issue “touching NaN”; the issue would be trying to pack some additional information into the fraction bits of the NaN, and expecting every implementation to treat it the same.

cylon13 5y ago
Yeah, that's a good point actually.

wiqar 5y ago

Hi, I'm Wiqar, product manager for Wasmer. We would love to hear more about your application and use case. Is the app in production?

cylon13 5y ago
The game using Wasmer is currently fairly early in development, but we have a few games in production built using various technologies, with the most recent one that I worked on done entirely in typescript. Both this previous game and the upcoming game are fast-paced action games. As much as I enjoy typescript, there are lots of annoying things that crop up in game dev in particular with regards to memory management, such as needing to pool instances of small classes, etc, so I figured it's time to switch to rust+wasm since the ecosystem seems mature enough now for it and Rust is a joy to program in. The architecture of the games are such that the main game logic runs both on the client and the server. The server runs the logic to provide the authoritative game state and send it out to all the clients, and the clients run the logic to predict where they're going to be immediately after you press an input to compensate for the network latency. Since the client is predicting what will happen using the same code paths, the game logic need to be completely deterministic so that it desynchronizes from the server as little as possible. With the TS/JS game we essentially just hope that running the same JS bundle in node and any client browser produces the same results for all the collision/gameplay math, and it seems to luckily not cause us any problems. For the game in rust though, compiled and optimized native rust floating point math would drift from our client webassembly builds surprisingly quickly, so we decided to pack all the shared logic in to a wasm bundle that gets loaded on both the server and the client, and we're using Wasmer to do that :) The Wasmer API is super ergonomic and it's been a pleasure to work with. I think the only thing that would make our lives better that I can think of is being able to ignore imports and have them auto-bind to noop functions or functions that immediately return zero in the case of non-void imports. Since we're using the same wasm bundle for the client and server, there's a bunch of client-only rendering bindings that we just ignore and never call from the server-only and shared wasm code in the bundle, and currently we're using a hacky script that uses wasm-objdump to generate a rust module with a bunch of noops in imports!{}.

astlouis44 5y ago

Interested in hearing more about your browser game. Another dev and I are working on a next gen HTML5 gaming platform using WebGL/WASM, and we're looking to back developers creating interesting titles. We provide access to our suite of devtools for optimizingprojects for the browser, and deploying on our platform. Link to our Discord if you're interested in discussing this further: https://discord.gg/zUSZ3T8 https://discord.gg/zUSZ3T8