good lord, a physics card.

[Rotting Corpse]

Well, they might be the next big thing in pc gaming sooner then we all think. I know the new Ghost Recon game all ready takes avantage of a physics card.

You need to install the AGEIA PhysX software even if you dont have a card even if you playing the demo.

[Csonicgo]

do you think physics could be handled by the multiplayer servers?

[AndrewB]

Backending the physics would be extremely demanding on bandwidth, meaning (let's not kid ourselves) monthly subscription fees to play the game.

It's been done before and it'll be done again, but count me out.

[Fredrik]

The problem wouldn't be bandwidth but lag.

Unless you'd be happy with prerendered physics.

[AndrewB]

Like I think I've mentioned earlier on the thread, send the basic player input over the network, and let every computer figure out the end result. Fewer packets, faster games, better experience for everyone. If Doom can do it right, then any game can.

[Fredrik]

But less energy-efficient, which means more bunnies dying from global warming and radioactive waste.

[GooberMan]

Let's assume that it would be better to send physics data over the network for every object in the game.

Assume we've implemented a rigid body physics system. Each object is made of points joint together by distance and angular constraints. You could do it with springs instead, but that implies keeping track of velocity, which we can avoid by implicitly tracking velocity through keeping track of the last frame's position and locking the timestep off to a fixed rate. Not having to track the velocity already cuts the data we have to send in half.

Assume there's 5000 unique points in the system (looking at the Cell Factor video, it's not hard to imagine there being more). To ensure these are in sync every frame, you'd want to send every position of each object every frame. Assuming it's stored as a three-dimensional vector with each component represented by a 32 bit floating point number, that's 60,000 bytes of data per frame that needs to be sent. Assuming our timestep is 1/30th of a second, that's 1,800,000 of date per second - or 1.7 megabytes. With compression, it could probably get down to about a megabyte per second. Unless I'm mistaken, no average household consumer has an internet connection that fast.

Which brings us back to the post I made in this thread about reproducability of gaming systems.

[myk]

Fredrik said:
But less energy-efficient, which means more bunnies dying from global warming and radioactive waste.

That's not right; it would surely piss Adrian Carmack off. He likes to behead and impale the lil' buggers, and it's no fun if they're already dead.

[AndrewB]

GooberMan said:

Let's assume that it would be better to send physics data over the network for every object in the game.

Assume we've implemented a rigid body physics system. Each object is made of points joint together by distance and angular constraints. You could do it with springs instead, but that implies keeping track of velocity, which we can avoid by implicitly tracking velocity through keeping track of the last frame's position and locking the timestep off to a fixed rate. Not having to track the velocity already cuts the data we have to send in half.

Assume there's 5000 unique points in the system (looking at the Cell Factor video, it's not hard to imagine there being more). To ensure these are in sync every frame, you'd want to send every position of each object every frame. Assuming it's stored as a three-dimensional vector with each component represented by a 32 bit floating point number, that's 60,000 bytes of data per frame that needs to be sent. Assuming our timestep is 1/30th of a second, that's 1,800,000 of date per second - or 1.7 megabytes. With compression, it could probably get down to about a megabyte per second. Unless I'm mistaken, no average household consumer has an internet connection that fast.

Which brings us back to the post I made in this thread about reproducability of gaming systems.

WOAH that's a lot of fudgy fudgy assumptions!

[fraggle]

AndrewB said:

Like I think I've mentioned earlier on the thread, send the basic player input over the network, and let every computer figure out the end result. Fewer packets, faster games, better experience for everyone. If Doom can do it right, then any game can.

Doom doesn't do it right. Architectures of the kind you describe don't scale to more than a few players.

[Csonicgo]

perhaps the client could use prediction and interpolation on the physics movements? having the server send basic physics data and having the client work from there could work...

[cycloid]

there's a lot of theoretical optimisation that you could do

1. only physics events that then player can see are sent, and only in a basic form

2. only events that are near enough to the player to require a player/plyer-weapon collision response are sent, in a higher precision form

3. other events are client predicted, requiring only occasional (and distributed across all events) heartbeats

4. non moving entities do not transmit anything



e.g. a swining pendulum can be left to it, with only the occasional server heartbeat to keep it in sync. but if another player fires a grenade that bounces off the pendulum then only a small number of things need to be transmitted:

1. the original launch velocity of the grenade then...
2. the positions and velocities of both the grenade and pendulum before and after the moment of impact

indeed a good physics system will be able to trace ahead (on the server) and see into the future what's likely to happen (e.g. the grenade will hit the pendulum in one second, presuming it doesnt explode or nothing else gets in the way) and so the second update above can be prepared, cued, and sent in time for the client to cache it, ready to spline towards that moment in the future. this is only the same as player prediction where a player will run into an area only to be snapped back after a moment of lag because what happened on the server is that a grenade went off and knocked them sideways. under good network conditions such occurences will be minimal.

so with some clever programming, a timeline cache on the client that can stretch several seconds into the future and a robust non-random-number-utilising physics engine i dont see why massive amounts of bandwith would be needed.

the biggest issue, in terms of bandwidth, i foresee is that of games like GTA. to do a multiplayer GTA where all the AI controlled characters and vehicles were in sync would be a lot harder, because unlike physics the AI could not be easily predicted (due to it's reliance on random events), or could it? if it were seeded, and like the physics only player interference with the AI elements were transmitted in high-precision form? hmmmm

[AndrewB]

cycloid said:

stuff

Those are all good ideas, but the #1 obstacle will be the developers being too lazy to work on anything that sophisticated. They'll likely try to push everything through the network and on the box under system requirements put "3mbps or faster connection for internet play."

(Again, an exaggeration, but I wouldn't bet against it.)