Using Babylon/Havok WASM module in a Golang server

Questions
1

The team here is designing a intensive multiplayer game, with the server Golang based, and the client being web focused with Babylon as the engine.

Considering the current (and strong) recommendation of Babylon documentation is to use Havok for physics, we have good reasons to want it in the server-side also: We will need a lot of physics calculations and checks in the server to offer a single source of truth of players position during the game-play; And potentially to help detect and block cheaters.

So, in short, the questions are:

  • Can we use the @babylon/havok .wasm module at the server-side?
  • And can we use it on something other than Node.js, that means, with Golang?
  • If so, is there some kind of documentation for doing that?
2

Adding @carolhmj and @RaananW but I am not sure Havok was working in node :frowning:

3

If you’re just running the plugin itself, I think it would be possible. A quick search shows there are packages to run WASM content in Go: wasmerio/wasmer-go: :hamster::spider_web: WebAssembly runtime for Go (github.com), so I’d check this method :thinking:

1 Like
4

Thanks for the reply @carolhmj, indeed we think it’s possible bind WASM calls inside Go, but we’re a little confused here regarding what exactly to bind to.

Is there any public documentation regarding the methods exposed by the Havok WASM module, that we could try to create a wrapper on top of it, in the same way you guys created the Node module?

5

I think you should reconsider your choices

6

I think we should check what would be missing to run fully in node with our wrapper ?

7

Hey @jeremy-coleman, we are still in an early stage, so reconsidering our choices is possible.

But I’m not sure to what direction to reconsider. Since we’re aiming for web games and high quality rendering with WebGPU, Babylon seems to be the choice. And considering that Babylon 6 has put all the efforts on Havok, and turned it the only recommendation for the new physics engine, I supposed it’s the only way to go.

So, could you please expand on what choice you think we should do differently?

  1. Stick to the old physics engine on the client (with Ammo), since Bullet is available for Go?
  2. Forget the physics on the Go server, meaning a single source of truth during multiplayer is basically impossible for now?
  3. Avoid Go at all, sticking to Node to be able to use the WASM module from there?
  4. Something else I didn’t got yet?
8

Maybe you could use GO for the main servers and a single node instance to run the physics server side ?

9

if you’re implementing it in a different language you can use whatever on the backend since youre giving up code reuse and babylons physics plugin is flipping coordinates… theres not going be a 1:1 mapping to the wasm module. Also, v8 is obviously going to be way faster than go with some frankenstein shitty wasm vm duct taped on top, so i think thats counter productive to your goals to try to use havok wasm from go. If youre using websockets Id say use node/uws with babylon thin engine for code reuse. Or if go/bullet is good, theres no reason that would stop you from using havok on the client.

10

Well, the idea of adopting a more modular micro-services inspired architecture for our game is being discussed here, and we like it indeed. Having a physics service written in Node, or even in pure C++ directly talking to Bullet, is really an option.

But as we know, a scalable multiplayer game must run physics simulations in the server to generate authoritative updates that are cascaded down to the clients. The client itself only runs smaller physics simulations that don’t have an impact in gameplay.

As such, we have the challenge that server and client must be able to predict each other’s calculations in order to compensate for latency (while the actual calculations are being executed and their results, transmitted). That’s the reason why we had in mind that the server and the client should be using the same physics engine - to avoid a mismatch between how the same calculation is made.

Does our reasoning make sense?

1 Like
11

Trying to use the havok wasm module from go just doesnt make sense imo. The other options seem fine.

12

Hi, I’m running into the exact same architectural issues mentioned here (I also want to use golang for server and babylon.js for client). May I ask what language/architecture y’all ended up using? Thank you!

13

@ErickPetru I agree with others on using Havok in Node, though your post got me curious whether Havok could be used in Go! So I explored this a bit

Here’s a working proof of concept: GitHub - regnaio/havok-go
I used wasmer-go as @carolhmj recommended

git clone git@github.com:regnaio/havok-go.git
cd havok-go/

go run ./main.go

# stdout (from running HP_GetStatistics): -2147024809

Seems like it’s hitting this code path in HavokPhysics.wat:

(func $HP_GetStatistics (export "HP_GetStatistics") (type $t3) (param $p0 i32) (result i32)
    (local $l1 i32)
    (if $I0
      (i32.eqz
        (local.get $p0))
      (then
        (return
          (i32.const -2147024809)))) // <--- Seems like it's hitting here
    (v128.store align=4
      (local.get $p0)
      (v128.load offset=32 align=4
        (local.tee $l1
          (i32.load
            (i32.const 50448)))))
    (i64.store offset=16 align=4
      (local.get $p0)
      (i64.load offset=48 align=4
        (local.get $l1)))
    (i32.const 0))

I’m unsure how practical this approach is…

1 Like