Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Physics in a multiplayer environment

Author
Message
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th May 2012 19:30
Link
So this concept of physics in a multiplayer environment is always discussed with a degree of trepidation. I'm sitting here though thinking, why can't it work? These days we have cloud gaming where the player input gets piped to a server, it does it's magic, and it sends back the visuals. If the modern internet is fast enough to do that, why can't I:

- Receive player input and move the player around at the client, sending this positional data to the server
- The server process this positional data and handles all of the physics. No physics is performed at the client at all, EXCEPT player collision with the static world.
- The server sends back the position of all physics objects to all clients, whenever they move.
- The client does the usual interpolation and smoothing of object positions, including those for physics objects.

This would result in a consistent world full of physics entities in a multiplayer game. The only downside I can see is more data being sent across the network, and a tiny lag for physics items. But surely the data would be minute compared to cloud gaming graphics data, and the delay would be negligible.

What do people think? I've been skirting around the issue of full on interactive physics entities in Carnage, because of the multiplayer issue, but I'm starting to think it should be possible. Any issues I've not thought about?

Back to top
Profile PM
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 17th May 2012 19:47
Link
The main problem is probably that the server will have to constantly keep track of all physics happening anywhere in the (supposedly very large) game world whereas in a local application you can shave away the stuff that isn't happening in the player's proximity.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th May 2012 19:50
Link
Yeah, that's a good point. Luckily, the world in my game is quite finite. Everything happens within an arena, so the quantity of physics items will be relatively low, and the majority of them would have to be processed by all clients anyway. So that shouldn't be a limitation for me.

Back to top
Profile PM
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 17th May 2012 19:54
Link
I cant see the physics affecting positional data so why not build it into the game engine itself?

I will not lie I too have pondered this very exact concern...

Back to top
Profile PM
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th May 2012 20:03
Link
Do you mean, why not have the client run it's own physics simulation?

Back to top
Profile PM
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 17th May 2012 20:09
Link
well, yeah

Back to top
Profile PM
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th May 2012 20:16
Link
Because physics systems are too unpredictable. If we both jumped into a multiplayer physics game now, and you ran into a load of boxes, on your machine it'd fall one way, and on mine it'd fall slightly different. That's all because of different CPU speeds and calculations, and those minor differences all add up to the simulation becoming radically different.

So the problem becomes, when I'm running through the world and shooting at you and apparently hitting you, you're crouching down behind a physics crate which happens to be in a different place on your version of the game. I should be killing you on my machine, but you should be safe on yours. So the physics worlds need to be identical to each other to avoid that scenario, and therefore each physical item needs to be simulated on one machine and sent to all the others, to make sure it's in the same place on all compos.

Headache!!

Back to top
Profile PM
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 17th May 2012 20:21
Link
timer based movement with position x,y,z objects or simply make a static world or static destructable objects like in CSS, though some can move... I am sure sending data regarding inanimate objects wont stress the server...

Back to top
Profile PM
Mr Bigglesworth
18
Years of Service
User Offline
Joined: 4th Mar 2008
Location:
Posted: 18th May 2012 04:16
Link
I have wondered this same problem myself...
Back to top
Profile PM Email
zeroSlave
17
Years of Service
User Offline
Joined: 13th Jun 2009
Location: Springfield
Posted: 18th May 2012 09:08 Edited at: 18th May 2012 09:09
Link
This is an interesting thing to ponder. What about having the initial player collision detection handled on the client, and the world collision responses handled on the host's side? If that makes sense...?

I just reread your first post and I think this is exactly what you stated.

Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
Back to top
Profile PM Email
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 19th May 2012 16:03
Link
Quote: "timer based movement with position x,y,z objects or simply make a static world"


The point is that two physics engines will not simulate the same environment regardless if the conditions are identical, so ultimately, it will have to be run by a single engine.

Back to top
Profile PM
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 19th May 2012 16:06
Link
So lets look at various multiplayer physics based games...

U3 as in UDK used PhysX for its engine... Thats per client...

So I would pressume CCSource uses server side?

Back to top
Profile PM
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 19th May 2012 16:19
Link
Quote: "Thats per client..."


How do you know?

Back to top
Profile PM
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 19th May 2012 19:51
Link
Because end clients need to install the api drivers... Or well the PHYSX dribers...

Back to top
Profile PM
Indicium
18
Years of Service
User Offline
Joined: 26th May 2008
Location:
Posted: 19th May 2012 20:43
Link
So? All that means is that the client has the functionality to run the physics simulation, which would be required if the client was hosting, meaning that the client was technically acting as a server.

Back to top
Profile PM
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 19th May 2012 20:48
Link
interesting...

Back to top
Profile PM
Scraggle
Moderator
22
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 20th May 2012 01:13
Link
The simplest solution is to use one-way physics objects - The player affects the objects but the objects don't affect the player. The same with projectiles - they affect the physics objects but the physics objects are irrelevant to the projectiles.

Of course, this does limit gameplay. Using a system like this, you can't use physics objects as weapons like knocking boxes into other players for example. But if you can limit your physics objects to one-way so that they are just there for show then you can utilise client side physics and all your worries are over.
Back to top
Profile PM Email
Michael P
20
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 21st May 2012 23:42 Edited at: 21st May 2012 23:43
Link
Yeah Scraggle makes a good point. If you think about counter strike source (CSS) for example, there is actually very little in the way of shared physics between clients.

For example, ragdoll physics is all done on the client side, so players die in different positions. I know this because I've been in situations where my friend tells me he's shooting a dead guys head but to me it looks like he's shooting the floor.

So the motto is 'keep it simple'. There are isolated cases where complex physics is needs to be shared precisely between clients e.g. grenades, but because these are limited the load on the server is kept low.

Now I am not 100% on the specific of this but I know it is 'roughly' correct. Most games, including counter strike source, actually do physics on BOTH the client and the server side at the same time, and then the client later makes corrections based on information from the server. The server handles the critical stuff such as player health, so it doesn't matter so much if clients have slightly different perspectives of the world.

The reason this is done is because of latency, for fast paced games like CSS, we can't wait for information for the server before displaying it on the screen, so the client makes a guess which is usually close enough.

An example of this in CSS is where I have shot someone, seen blood on their face, but their HP remains 100. This is because the predictions made on my client were wrong vs the simulation made on the server.

Similarly I remember a few times in Halo seeing a car fly to the right for a second and then bounce back to the left. Again this is where the client's prediction has been wildly out.

Lastly, I don't agree with the idea that the reason for these differences is differences in CPU etc.. I don't see how that can be true since this is math, and CPU all do math more or less the same, maybe a bit less precise but not to the extent that you would notice it. The real reason for differences is latency, this effects where our client thinks objects are relative to the server and therefore has a big impact on the result of the simulation - its a case of garbage in garbage out, if you start off with the wrong positions you will end up with the wrong positions.

May be totally wrong but I think this technique is known as interpolation.

DarkNet - multiplayer plugin
Back to top
Profile PM Email
MrValentine
AGK Backer
15
Years of Service
User Offline
Joined: 5th Dec 2010
Playing: FFVII
Posted: 21st May 2012 23:51
Link
Michael P

TOTALLY!

Back to top
Profile PM
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd May 2012 01:43 Edited at: 22nd May 2012 01:44
Link
@Fallout
Yeah, practically all games do exactly what you're suggesting already It would be next to impossible to replicate physics simulation results back from the clients to the server.

Quote: "I don't see how that can be true since this is math, and CPU all do math more or less the same, maybe a bit less precise but not to the extent that you would notice it."


Not strictly true. First of all even in the same CPU architecture, the requirements of the floating point unit are not specific enough to guarantee the same results on all systems, and even on the same CPU there are different modes of operation for the floating point unit to be in which have different accuracies. With something like a physics simulation the tiniest difference in values can produce a completely different simulation.

For example: imagine a box falling. Depending on which of its corners hits the ground first it will bounce completely differently, but even the tiniest difference in the rotation of the box at the point where it hits the ground will change which corner that is. Then you have to take into account the integration: physics engines only roughly approximate the integration of acceleration into velocity and velocity into position, and the slightest difference in the time-step used can produce completely different results.

Latency only really has an effect if something changes that the client couldn't have predicted (such as input from another client) since all the packets are time-stamped, so the client knows the exact state of the simulation at the current time minus the ping, and so if the simulation could be repeated perfectly, it could simply be stepped forward by the ping time.

[b]
Back to top
Profile PM Email Website
Benjamin
23
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 22nd May 2012 10:32
Link
Take a look at these two links:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://udn.epicgames.com/Three/NetworkingOverview.html

The latter is not so specific, but it should still be useful to you.



Support a charitable indie game project!
Back to top
Profile PM Email
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 22nd May 2012 10:35 Edited at: 22nd May 2012 10:36
Link
Quote: "Not strictly true. First of all even in the same CPU architecture, the requirements of the floating point unit are not specific enough to guarantee the same results on all systems, and even on the same CPU there are different modes of operation for the floating point unit to be in which have different accuracies. With something like a physics simulation the tiniest difference in values can produce a completely different simulation."


Exactly. I mean, currently my game is setup with a stack of 5 boxes for testing. Every single time I run it, the results are different. Sometimes the stack stays standing, but the staggering is always different, and sometimes it falls over, always in different ways.

Also, in a time independent system, the physics simulation has to figure out what happened over the given period of time. If I'm running at 100 FPS, the physics system must calculate what happened over the last 100th of a second. If another machine is running at 30fps, it's 1/30th of a second. The calculations performed on both machines are completely different in this case, as as Diggsey said, with it being an approximation, the results would be wildly different.

I can still see how some physics could be performed at the client, such as basic "player to static world" collision. The server can take the player position and speed and apply the correct forces to the physics objects, then send those physics object values back to the clients.

I can see how it'd be possible for the client to run it's own local physics simulation, then interrupt it to update it's position and velocity values with those sent from the server (and smoothly interpolate between them). That may be too complex though.

I guess it depends on the game. For some games, waiting for the duration of a ping to start moving physics objects maybe ok. For example, if a character runs into a physics object, if the client doesn't handle physics, it'll run inside. However, it'll only be inside it for the duration of the ping, at which point it'll receive a positional/velocity value from the server saying how the box is moving, the box will be repositioned in front of the player, moving away, and everything will be ok once more. For slow moving games, I'm thinking that'd be fine.

Back to top
Profile PM
Scraggle
Moderator
22
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 22nd May 2012 11:18
Link
Just to clarify my point again:
If the player/projectiles affect the physics objects but not the other way around, then the client does all the physics calculations but doesn't need to update the server or other clients because the position of the physics objects is irrelevant to the system.
For example: In your five stacked box example, if you run that as a multiplayer test, then one player could knock the boxes over but all the other players would still see five stacked boxes because they are for show only and don't affect the game-play at all.

Like I said in my previous post, that does limit the game-play but if it is an acceptable limit then it makes your coding a hell of a lot easier.
Back to top
Profile PM Email
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 22nd May 2012 11:40
Link
I did take that on board before, and it's a very good idea. I may use that technique for things like random items of debris and other unimportant physics items.

Back to top
Profile PM
zootan
16
Years of Service
User Offline
Joined: 12th Apr 2010
Location:
Posted: 22nd May 2012 12:03 Edited at: 22nd May 2012 12:15
Link
it sound like a lot of work for the server . And would mean constant messages for all object positions to every client and to do it real time , if you cut down the amount of messages then you lose the quality you were looking for , dropped packets could also spoil the end result .

so with all the problems to do with message overload and the fact that vectors sent to different pc could have different end result , it gives you no advantage to do it like this when you could just have the client that interacts send out the result of new object pos /rot .
unless u have the cloud bandwidth and server capability.
Back to top
Profile PM
Fallout
23
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 22nd May 2012 13:26 Edited at: 22nd May 2012 13:27
Link
I don't know what you're envisaging zootan, but I'm not making a game with thousands of objects. I probably wouldn't have more than 100 physics objects in total. Essentially each one would just need float posxyz, float rotxyz, float velocityxyz, float rotational_velocityxyz. 12 floats per object. 1200 floats.

The server would only tell the client about the objects that were on screen (or close to being on screen) and moving. Values would be interpolated between a client side physics system.

Imagine this:
- Server runs a version of the simulation
- Client runs a version of the simulation
- The clients version of the simulation runs against hidden objects, so none of them are visible. Crates are being moved around locally, but you can't see them (excluded).
- A duplicate of all physics items is visible, and this is positioned using interpolated values between local and server physics system.

So it works thus:
1. Player runs along and passed inside a crate
2. Local physics system detects collision and starts crate moving
3. Server receives player packet, positions player and makes its version of the crate move.
4. Server works out this crate is of interest to the client, because its close to him and on screen, so sends its version of the crate simulation values back to the client
5. Client receives these new values and updates its simulation accordingly, instantly positioning it's invisible version of the crate to the coordinates and velocities
6. Over time, client interpolates the position/rotation of the visible crate to the invisible one
7. Client continues to run local simulation and update it with values from the server, interpolating the visible crate into position
8. When the crate stops moving, the server stops sending updates.

It's not exactly simple, but I think it could work and would be fairly straight forward ... in principle.

Back to top
Profile PM
Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 22nd May 2012 16:52
Link
You can't very well have any important part of the game simulated client-side because then it becomes very easy to cheat. Doing static collision on the client side only is the reason that "wall-hack" exists in many games

The only time you can safely do processing on the client is if it can be verified on the server. If it takes as much processing power to verify a solution as it does to find the solution then it may as well be done entirely server-side. (Interestingly, this means that the server-client model would be a great way to solve NP-complete problems)

[b]
Back to top
Profile PM Email Website
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 31st May 2012 00:27 Edited at: 31st May 2012 00:27
Link
I think we should take a step back here.
Everyone seems to be thinking of those PhysX demos with thousands of objects.

There is nothing stopping him from doing server side physics on a limited number of objects. If the game world only had 3 or 4 physics enabled objects then the issue of server workload is a non-issue. Also client-side cheating would be avoided.

Most effects are superficial, and can be client-side generated. Things like hair or cloth, where (for example) bullets pass through them.
I think most of us agree that in this decade, server-side physics on a large group of objects is still a technological limitation, and it won't always be.

Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2026-07-10 07:21:55
Your offset time is: 2026-07-10 07:21:55