Can you combine high playercount, multiplayer, physics and 60fps?

Hi,

I was wondering if it’s possible to use babylon.js to create a multiplayer game that has physics, a high playercount (think 100+) and 60fps?

Think of something like this (My idea is quite different, but this is pretty close in physics interactions and player count):

Could you make something close to this?

I realise even if this is possible, it would be an enormous task. I don’t expect to do this without any help or in a week, a month or a year, but just like China I make 5-year plans / budgets and choose the best one every 5 years. This is one of my contenders and I would love to hear some honest feedback from the community before I decide and invest a lot of time/money. Please don’t hold back.

Here are some of my thoughts, so you can better determine if I have any chance to succeed:

  • Networking over UDP (for example with geckos.io made by @yannick) or if available and better WebTransport / QUIC;
  • Should use Web GPU on launch (should be available by then);
  • Either put the physics in a webworker or try to offload to the server;
  • Use instances and SPS wherever possble;
  • Every choice will be made with performance in mind, from map / character / items / physics imposters to deciding on which physics engine to use (basically perfomance testing at every turn);

If you want me to clarify something or if I forgot something, please let me know. I tried to keep it pretty succinct.

I would also appreciate it if you could share any other methods like SPS that would help achieve the above.

Kind regards,

Justchat

The main issue I’m seeing is about multi threading. Rendering is not the big deal here. The problem is making sure all that world is synchronized, that physics can be run off thread etc…

I do not say it is impossible (see https://shellshock.io/ which is bjs based), I’m only saying due to the nature of the web it will be challenging

2 Likes

I think, a game like Buy Fall Guy should easily be possible (maybe not up to 100 players at the same time, but I don’t know). Besides geckos.io, (which will use any better networking solution like WebTransport or QUIC once available), I have also coded packages like Snapshot Interpolation and Typed Array Buffer Schema which will help you a lot.

Another project of mine called enable3d.io, offers a nice headless mode, which allows you to run ammo.js server side.

So I would calculate the physics on the server (enable3d) send positions/rotations to the players (using geckos.io and compressed with typed array buffer schema) and interpolate the positions/rotations on the client (snapshot interpolation).

Hope this helps :smiley:

4 Likes

Agreed, this should be possible. A potential blocker is mentioned in computeWorldMatrix gives delayed positions when using Physics in onBeforeStepObservable.

If this is resolved, we can have deterministic physics with accurate position tracking, so you could send correct positions between server and client.

1 Like

@Deltakosh

I’m only saying due to the nature of the web it will be challenging

Unfortunately I agree, there are a lot of constriants to think about and some limit the design choices quite a bit.

@yannick

I have taken a glimpse at your other projects and they look very interesting, especially enable3d.

@gbz

If this is resolved, we can have deterministic physics with accurate position tracking, so you could send correct positions between server and client.

Even with large player numbers? Or do you think I need to consider a lower amount?

I think this can be done with a player count as high as 100 or even more. This would require a minimum of 100 moving physics impostors (on the server and maybe client), though 60 FPS may still be achievable.

Snapshot interpolation as @yannick mentioned sounds like a great idea, and maybe you could avoid running client-side physics for the other 99 players and just position them according to the server. (This especially works great if players are allowed to pass through each other.)

@yannick’s enable3d demo is amazing. I was surprised by how high the FPS was (easily >100 FPS on older machines with disabled frame rate limit) despite every object in the scene being collidable with good precision.

1 Like

I would be surprised if this is not possible within 5 years. I think it could be done today with a bit of cleverness if all 100 are on modern hardware with great internet.

1 Like

Thx :slight_smile:
Every object in the scene uses a Ammo.btBvhTriangleMeshShape. It should even get a better performance once I port the whole physics into a worker. Here is a simple demo I created.

4 Likes

Whoaaa that’s crazy fast!

2 Likes

This looks great.

I do have a question though, why do you use three.js instead of babylon for enable3d? And are you planning on sticking with three.js in the future? How hard would it be to use babylon instead (if I want to rewrite it)?

I will stick with three.js. But maybe in the future, the physics part will be available for babylon as well.

Well, babylon and three have a completely different API, so a complete rewrite makes no sense.

But I did not share enable3d with you as a replacement for babylon. If you are already familiar with babylon, you could use babylon on the client side (without physics) and calculate all the physics on the server side using enable3d in headless mode.

1 Like

That does make a lot more sense than what I was proposing. I blame the heat :stuck_out_tongue: .

Thanks for all the help and all the cool libraries, I am going to slowly build out my plan and go from there. I’ll also keep a watch on your progress on enable3d, because your webworker example looks awesome, can’t wait to try it myself.

2 Likes

@yannick, would be so amazing if you had the time to create a similar worker physics demo for Babylon! Thank you for sharing your awesome tools :smiley: