I've been integrating some APIs into idtech3, with varying degrees of success, and I've been considering using the Bullet 3 API as well, but I'm not sure how well Bullet would work for replacing all of the collisions between the player and the world, and have it be networked. A huge part of Quake is the responsiveness, and the reliability with which you could predict your own interactions with the world. So I'm wondering how different it might be if I were to use a pill collider, with full range motion and rotation. Would it be too slow to actually be networked across, say 24 different players all colliding, rotating, and sliding across the world?
I am not likely going to use player to player collision for this project. Thoughts?
Networked physics? (idtech3)
Re: Networked physics? (idtech3)
(I have never used idtech3 before.)
To answer "Would it be too slow ..." ...
How many objects/constraint in your world?
How complex is the map?
It also depends on many customize-able setting e.g. friction, restitution, time-resolution ...
Generally, 24 dynamic bodies are far from "too many".
IMHO, Bullet can do such multiplayer game if it is done in a right way.
I am not sure if this answers your question.
To answer "Would it be too slow ..." ...
How many objects/constraint in your world?
How complex is the map?
It also depends on many customize-able setting e.g. friction, restitution, time-resolution ...
Generally, 24 dynamic bodies are far from "too many".
IMHO, Bullet can do such multiplayer game if it is done in a right way.
I am not sure if this answers your question.
-
drleviathan
- Posts: 849
- Joined: Tue Sep 30, 2014 6:03 pm
- Location: San Francisco
Re: Networked physics? (idtech3)
I think Bullet would have no problem doing the physics for a networked game with 24 capsules and a reasonable amount of game level geometry. As far as Bullet is concerned the issue is number of objects and complexity of their shapes. On modern hardware Bullet can push thousands (if not tens of thousands) of simple objects around and hundreds (if not thousands) of reasonably complex objects, no problem.
Your primary challenge would be the network effects of trying to synchronize the physics one various clients. If you're writing a twitchy first person shooter game like Quake AND you expect your players to have very bad ping times then you may need to do the things that Quake did to make a fun game, else either: (a) your game won't work for people with long ping times or (b) there will be ways for players to exploit bad ping times to cheat. But remember, back when Quake came out games typically ran at 30 Hz or less and ping times could be a second or more. These days it shouldn't be too hard to make a 24-player networked game run at 90Hz and most ping times will be 200msec or less. Of course, if your game gets enough interest to make it worthwhile to cheat then players can always artificially increase their ping times if it helps them. Ask yourself: do you want to worry about cheating players? If not, then the project will be less complicated.
There is a very good presentation from GDC-2015 by Glen Fiedler (aka Gaffer on Games) about how to implement networked physics for games. I recommend it to anyone who might want to write a networked physics game.
Your primary challenge would be the network effects of trying to synchronize the physics one various clients. If you're writing a twitchy first person shooter game like Quake AND you expect your players to have very bad ping times then you may need to do the things that Quake did to make a fun game, else either: (a) your game won't work for people with long ping times or (b) there will be ways for players to exploit bad ping times to cheat. But remember, back when Quake came out games typically ran at 30 Hz or less and ping times could be a second or more. These days it shouldn't be too hard to make a 24-player networked game run at 90Hz and most ping times will be 200msec or less. Of course, if your game gets enough interest to make it worthwhile to cheat then players can always artificially increase their ping times if it helps them. Ask yourself: do you want to worry about cheating players? If not, then the project will be less complicated.
There is a very good presentation from GDC-2015 by Glen Fiedler (aka Gaffer on Games) about how to implement networked physics for games. I recommend it to anyone who might want to write a networked physics game.