4 ms·

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?

by wiqar 5y ago

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!{}.

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?

by 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!{}.