1000 boxes/pipes/cans will it bog down your network?

[SockMan!]

The scenario I assume you're discussing is tracking the effect of bricks from the collapse, say, hitting a particular player local or remote. Someone playing in the environment using a physics processor has an advantage in which more bricks are visible and can therefore be avoided. A remote client without a physics processor, however, should still take damage based on the proximity to the collapsing wall but there will be less visual feedback to help avoid the falling bricks.

In neither scenario is it necessary to transmit data about the status of specific falling or collapsing objects.

This works well for the current physics model in regard to compressibility over the network. But when future games crank up the real physics - stuff like deformable interactive enviroments, interdependent physics, and ongoing effects - it'll become a much more complicated issue. For example, cascading physics such as realistic earthquakes would require massive amounts of processing server-side - it's also necessary to transmit a lot of data to the clients since the earthquake affects how the game is played (and you can't just send outcome data because what happens during the earthquake matters too). While the server and clients will only transmit data required for gameplay, it may become unavoidable to have to send data about thousands of objects across the network anyway.

Of course, whether the server can even handle the load is another matter. Maybe they will by the time 'realistic' physics becomes mainstream? Who knows when that will be...

 

[MH Knights]

I always thought a set up would work like this:

• The server would have a PPU that calculates all Gamplay Critical Physics, which would be things like projectile trajectory, shrapnel, damaging debris.
• The client would have a PPU that just calculates Eye-Candy Physics such as cloth/hair, foliage movement, particals, non-damaging debris. A client without a PPU would either have to turn these effects off or tone them down.

I have been saying since the begining that PPUs may only catch on for dedicated servers/professional applications.

I see bandwidth as a huge limiting factor in regards to large multiplayer games. I pay for 3M down/256k up but I am lucky to get 500k down (I average about 350k to 400k)! Uploading I only get about 30 to 40k. With numbers like these trying to play a game with thousands of interactive objects or enviroments is imposible. ISPs are slowly raising numbers but the future doesn't look good.

 

[drizzt81]

While I know that it's bad form to bump old threads, this thread already has a lot of discussion about the topic I wanted to post:

Many people on this subforum in particular make claims about the 'obvious' impossibility of having gameplay physics work in multiplayer. Unfortunately, I do not know what most of you do for work, so I am unaware of anyone's extensive experience in writing multi-player games and the associated network code.
I have looked through this thread and found lots of speculation about why gameplay physX are not networkable, at least not on a low-Mbit connection. While there is a ton of speculation, there is no supporting documents, or at least claims of people actually knowing what they are talking about. It seems that many people in this thread have taken the 'I don't know how to do it, so it must be impossible' stance, which I think is extremely flawed. I don't know how to build a car engine, yet they still exist and work.
Anyway, the lack of supporting evidence making sure that PhysX is not networkable makes me wonder why some people are stating such speculation as if it were proven fact.

Do I know whether and how to make PhysX work in a networked environment? Well, I have some ideas that may work, but nothing for sure. However, seeing that making statements that are likely to be true in the future appear to have little impact, let me state my "facts" here:

I think that an all physX multiplayer game is possible. I don't think that it would be more lag dependent than any other game:

The only 'active' part in a multiplayer game is the player, i.e. the human. All other objects in a game depend only on the player action, which means that if we are able to transmit the actions that a player takes to the other players, there should be not problem to calculate the outcome, since everything in the computer world is (can be made to be) deterministic: with the same seed, most random number generators are going to be spitting out the same sequence.

So, given that everything but the player is deterministic, which includes specifically all physics calculations, adding more or less world detail to the simulation/ game does not influence the network code at all. While it is certainly correct that latency is going to slightly affect the game outcome, because certain events may have occured at time t, while the client receives notification of this at t+s, which will affect the world retroactively, but this is no different than most problems that current games have, regardless of a physX enabled environment.

Now, please go ahead and destroy me with compelling evidence to the contrary.

 

[SuperGee]

I think that an all physX multiplayer game is possible. I don't think that it would be more lag dependent than any other game:

Sure it is possible. CF:revolutions will be also supporting online.
Why because the gameplay Physics load is adustable to the server and client Net connection bandwide and lag capabilities. Such ADSL2
Wich means forget 64 player games. 4 or 8 at most. With the leatest and grates ISP high bandwith abbo's.

The only 'active' part in a multiplayer game is the player, i.e. the human.

The active part are all mutiplayer clients. Like those 64 player servers for BF2.
Mostly used in a star topolgy. All player conected to a central server. So you get a number of players client synchonisation load. The more player the more bandwidth needs the server must have. Each Mplayer must have enough bandwidth for the current Physic synchronatistion load.

All other objects in a game depend only on the player action, which means that if we are able to transmit the actions that a player takes to the other players, there should be not problem to calculate the outcome, since everything in the computer world is (can be made to be) deterministic: with the same seed, most random number generators are going to be spitting out the same sequence.

That's one trick to reduce net trafic. But this trick is already standard use for excisting games. So gameplay Physics generated more interactive objects. Wich means a lot more to synchonise.
Plus that seeding random trick is nice if PPU calculation are reproducable. These precalculation must be synchronised to to get the same result.
So in short, that old seeding trick is already avaible and still the load is a lot larger.
It's seeding trick on 100 objects and for a PhysX game it would be seeding 2000 objects.

So, given that everything but the player is deterministic, which includes specifically all physics calculations, adding more or less world detail to the simulation/ game does not influence the network code at all. While it is certainly correct that latency is going to slightly affect the game outcome, because certain events may have occured at time t, while the client receives notification of this at t+s, which will affect the world retroactively, but this is no different than most problems that current games have, regardless of a physX enabled environment.

Gameplay Physics produce a lot more objects wich produce a lot more events. So more net load. That why there is the Physx load slider to adjust to net power avaible. Less Physics able object generated.

Now, please go ahead and destroy me with compelling evidence to the contrary.

Well the most gameplay rich PhysX game will be also a multiplayer and online game.
CF:R
But not like massively like BF2. Only a few players and with adjustable Physics load.
So artifical studios and immersion studio thingin otherwise then you.
Gameplay PhysX means a lot large net load. That's a fact. And they deal with that in two way's.
1 ) a practical limit of 16 player. for CF:R
2 ) Wich is possible due to a PhysX slide to adjust this load. Other wise it would be less 4?
* ) Cf:CT is a 4 player Lan game. That give you a hint off the load.
* ) Wich means the online experience is a reduced one what Lan player can set for.

To play CF:R online a ADSL2 for each player would be nice to be able to cranck up the PhysX.

And those Dev's are optimizing the net code surely.

 

[drizzt81]

Sure it is possible. CF:revolutions will be also supporting online.
Why because the gameplay Physics load is adustable to the server and client Net connection bandwide and lag capabilities. Such ADSL2
Wich means forget 64 player games. 4 or 8 at most. With the leatest and grates ISP high bandwith abbo's.

So CF:Revolutions features the very best networking implementation that there is? Mind telling me where I can read about it? Or do you happen to be a developer on this project?

The active part are all mutiplayer clients.

yes and no, if by "client" you mean player, then you are correct. The only truly random variable in any system is the human that is interacting with the system. While this random variable 'drives' the rest of the system and has a large influence on the current systems state, at the same time this influence is limited to an area where this character is acting. Efficient map design can limit this.

Mostly used in a star topolgy. All player conected to a central server. So you get a number of players client synchonisation load. The more player the more bandwidth needs the server must have. Each Mplayer must have enough bandwidth for the current Physic synchronatistion load.

Thanks for lecturing me on the basics of networking. It is pretty straightforwards that more people will require more networking. There are -however- many ways to trade between bandwidth and CPU power. Have a look at rSync and you will notice that once there is a consistent initial state that was replicated across clients, changes can be transmitted with little bandwidth but high CPU load.

That's one trick to reduce net trafic. But this trick is already standard use for excisting games. So gameplay Physics generated more interactive objects. Wich means a lot more to synchonise.

How do you know this? Got some information that I can read that states that this is how games currently do it? Or do you work as a game developer? If neither of these are true, how do you know?

Plus that seeding random trick is nice if PPU calculation are reproducable. These precalculation must be synchronised to to get the same result.

All calculations in a computer are deterministic, so they can be reproduced at any time.

So in short, that old seeding trick is already avaible and still the load is a lot larger.
It's seeding trick on 100 objects and for a PhysX game it would be seeding 2000 objects.

and? So I need 20x the bandwidth at most, which comes out to be what? I do not know how much data CS:S generates, but if the built in netmonitor is anything to go by, on the 64player server I was just one (dust2) I got at most an incoming load of 22KB/s and outgoing of less than 13KB/s consistently.
If we increase the number of interactive elements a factor of 20, we have 440KB/s down and 260KB/ out, both of which are number that are not that far out from what my cable connection can do now. In fact, the gamer's package that comcast is offering is 1MB/s down and 80KB/s out. We can do an easy tradeoff to accomodate a 64-player game 20-fold increase in objects.

Gameplay Physics produce a lot more objects wich produce a lot more events. So more net load. That why there is the Physx load slider to adjust to net power avaible. Less Physics able object generated.

you require that all interactive objects are ones that need to be synchornized across the network. The nice part about the PhsyX architecture is that we can finally simulate things like friction in a more real-world approximating way, which is information that does not need to be synchronized across machines. Depending on the surface, and the slope that you are running on, your speed will vary. While there are quite a few interactions of objects to calculate locally, the other players do not need to get all the information, but just what is relevant to them.

Anyway, I would love to READ more about this and am curious where most of the people on here got their information from, since I like to educate myself. Please, help me learn.

 

[ZenOps]

Simple, have items that influence things, and items that don't.

If you have a thousand particles from an explosion, flag 988 of them as "no damage particles" just visual effect. Then it does not have to be calculated by a game engine as a hit. Have 12 larger chunks that explode from the object as actual damage inflicing particles that affect other particles (including players)

Each player may not see the *exact* same thing if the explosion is randomized, but at least the major chunks will be.

 

[jimmyb]

Gameplay physics over a network is a very tricky topic. Rather than attempting to explain myself, and have my authority questioned, I refer you to Tim Sweeney:

There are a number of networking solutions for physics, what we are doing in UT2007 is using the physics hardware only for accelerating special effects objects, things where the server tells the client, Spawn this special effect here! The client responds with an explosion with thousands of particles, and each of those operates as a separate physics object but it doesn't effect the game play... it’s just purely a visual effect there. That’s the easiest and most common solution.

Some of the other solutions it looks like other teams are using are only enabling the physics hardware's networking on a LAN environment, where the entire physics state of the world is being replicated to all the clients, that requires a vast amount of bandwidth, more than even a broadband connection has there, so that’s not very practical.

The other approach is to run a peer to peer lockstep game, which would be ideal for like a fighting game or some other game with 2 players or 4 players playing against each other where the entire game runs in lockstep, everybody has hardware and the entire game state evolves deterministically on all of the machines.

http://www.nvnews.net/vbulletin/showthread.php?t=70056

drizzt81 - You'll note that Sweeney does mention your deterministic/client-side approach to running physics. Aside from the issue that everyone requires a PPU, it also opens the door for some serious cheating: Two prospects I don't look forward to.

Addendum: Just occurred to me, the deterministic approach also requires that no LODing is being done by the client in terms of what affects physics.

 

[drizzt81]

Gameplay physics over a network is a very tricky topic. Rather than attempting to explain myself, and have my authority questioned, I refer you to Tim Sweeney:


http://www.nvnews.net/vbulletin/showthread.php?t=70056

drizzt81 - You'll note that Sweeney does mention your deterministic/client-side approach to running physics. Aside from the issue that everyone requires a PPU, it also opens the door for some serious cheating: Two prospects I don't look forward to.

Addendum: Just occurred to me, the deterministic approach also requires that no LODing is being done by the client in terms of what affects physics.

Thanks stuff like this is what i was looking for.

 

[Mega2]

that would be cool if the physic is run off the server and it sync with the client for game play and compress it over the network and the client physic uncompress it and sync to the server side physics. Then we can see some game play physics not just random eye candies that is better suit for video cards at 300$. Might put the nvidia dual lan 2 gbit into gbit router for some local lan server action.

 

[SuperGee]

So it's about this. I saw the interview video online a few weeks back. Very interresting. So I already new that.
PC vs PS3 online is possible. Xbox360 to but MS don't want that.
And UE3.0 will support DX10 someday.

@interview snipped.

Jacob- How about Ageia effects over a network? Is that supported or is it Client side? I imagine trying to push that amount of physics data through the network, there might be a bottleneck.

Sweeney- There are a number of networking solutions for physics, what we are doing in UT2007 is using the physics hardware only for accelerating special effects objects, things where the server tells the client, Spawn this special effect here! The client responds with an explosion with thousands of particles, and each of those operates as a separate physics object but it doesn't effect the game play... it’s just purely a visual effect there. That’s the easiest and most common solution.

This is a game design choice a dev made. Goin the easy way. to support the larger group of gamers instead using new hardware to the Max. It''s like Graw. But using Pure the PhysX API for EffectPhysics only. While Immersion/Artifical gone do with Cf:revolution. A gameplay PhysX game for online play to. A choice Dev's make. The go for the real deal. Using new hardware as it's ment to be. to the max. But still PPU is optional.

Some of the other solutions it looks like other teams are using are only enabling the physics hardware's networking on a LAN environment, where the entire physics state of the world is being replicated to all the clients, that requires a vast amount of bandwidth, more than even a broadband connection has there, so that’s not very practical.

That's what CF:CT is now. A LAN game Full PhysX if you enable Cloth's and fluids.
It would be also the optimal way to put revolution to the max.
A GameDesign choice for goin to the max. Wich is a nobrainer because it's goal was to demo PhysX. But keep in mind. UT2007 is a Online play focused game. Not all games have to be online focused.
While CF:Revolution is a Online game. They go to the trouble givin online gamers Gameplay PhysX at a Cost.

The other approach is to run a peer to peer lockstep game, which would be ideal for like a fighting game or some other game with 2 players or 4 players playing against each other where the entire game runs in lockstep, everybody has hardware and the entire game state evolves deterministically on all of the machines.

Well CF:Revolutions will be Client /Server. With 16Players it will be a star netplay scheme.

Well there are a lot of genres single Coop Multi player games. So There is room for a Heavy PhysX enabled game but UT2007 isn't one of them. It will have some cool PhysX effects. While CF:R will heve cool PhysX gameplay. Where you need a high upload bandwide. And limited to 16players. Where there is the option to lower the PhysX load on the Server. A trade off.

If you want to know more on PhysX PPU Network coding.
The Ageia Developer support site is what is best. But you must register for a PhysX API request to reach that Dev forum.

And so far I heard. Epic(UE3.0) is the owner of the Reality Engine(CF). So that's strange?
Artifisial is focusing on games

Well I also claimed that PPU needed a good balanced game rig the frame drop question. tim sweeny thinks also that way.

 

[jimmyb]

What he is saying is the there isn't enough bandwidth to run physics on a server-client topology over the internet (which would eliminate the need for a PPU anyway).

He does mention that gameplay physics could be done by each client in a p2p setup. This hasn't been a traditionally popular option in PC games because of bandwidth (scales n) and trust issues. It would also require that every player have a PPU.

 

[SuperGee]

Well the one say the other do it, the Server client PPU way where the client needs the PPU not the server.
You forget that Timmy says for 4 players P2P would be better to counter bandwith.
But CF:R will support 16 Player. Could be to much for effectivaly use the P2P method.
That game will requier some High bandwidth,compared to other games, for clients and server wich is the sum of all clients.
Could be a Home Server can do 2 to 4 players where a leased one could go for 8 to 16.
Or turn the Physics down.
I would play the game over LAN.

 

[jimmyb]

I didn't forget that "P2P would be better to counter bandwith". I said that p2p has traditionally not been a popular multiplayer solution because of bandwidth and trust issues. I am aware of how p2p would remove the necessity to send physics data across the network (compared to a client-server model). The underlying problems of a p2p system still remain though.

 

[Godmachine]

I do admit while having full fledged Physics acceleration is great ..piping it through a already confined and cramed internet is just gonna be task for sure. Playing Cell factor for instance online would be a mess i would think. Its so much data that would need to be passed back and forth through the net to get a full reaction from one side or another. I hope game makers are taking steps to prevent this from being a real issue cause as it stands right now ..sometimes you are lucky to land just ONE bullet in counterstrike when lag attacks.

 

[Unknown-One]

I think that an all physX multiplayer game is possible.

Well, it must work, because there's an MMORPG thats using it, Myst Online - URU:Live, which should be launching this christmas.

Its still in beta, and for some odd reason not on AGEIA's game list, but it does use PhysX and it will take advantage of a PPU if one is installed (try the beta installer if you want proof, it installs the PhysX driver).

 

[jimmyb]

You can be sure that accelerated physics won't affect gameplay though. Otherwise a physics card would be a requirement of the game, which isn't the case AFAIK.