some suggestions

[delerium10101]

SgtH3nry3 Wrote:Hmmm, you could take a complicated physics engine and only send the bone/joint-position data of a soft-body.

You send out 9 main bone/joint-positions over the internet from server to client (or when the client interacts with the body vice versa).
- 2x hands
- 2x elbows
- 1x head
- 2x knees
- 2x feet

This should be enough data, and shouldn\'t cause any lag, unless you would be playing on a 28.8k modem.

If you have like 32 dead bodies it shouldn\'t be more than 64kb of data, which is more than enough.

Then of course you\'ll have to count the other physics data too, but most of that can be done client-sided.
Except for street junk/props, like boxes, cartons, dragonteeth, hedgehogs, etc.

Everything sounds like it wouldn\'t be much. It always sounds like it wouldn\'t be much. Imagine a single object that needs a whopping 64 *bytes* per second to keep the client completely up to date. Doesn\'t sound like much, does it? Let\'s drop this into the worst case scenario. We have 128 clients connected to the server, and this object must update on all of them. We just hit 8 kilobytes per second to handle that. For that one measly object. But oh you say, that isn\'t much, cable can still handle that. Righto, continuing with this example (I actually coded this object, but pulled networking support for this reason, makes life fun, but it still works) we have not one, but three hundred of these updating at once. Minimal estimate really. Now, we have a problem. 2.3 MB per second, just for that object type. Out of the question.

It takes far more than 64 bytes/sec to transmit the correct position of an object over the network. It actually takes 896 bytes/sec, per client. Networked ragdoll is out of the question. Networked rigid body is bad enough, and this is exactly why. But yes, it is absolutely necessary that rigid body calculations be sent over the network. It\'s amazing just how quickly client and server can start to disagree.

Moving on, vehicles: Yes, there is a suspension and inertial system going on here. It sucks, but it works, and doesn\'t kill network performance (as much as previous examples). There\'s even a traction system which lets you pull slides under certain conditions.

Rigid body physics: Torque has its own rigid body solver. Again, it sucks, but it works, and doesn\'t kill network performance as much as ODE does. ODE has been successfully integrated into Torque, so long as its a single player game. There have been no playable networked ODE tests with Torque. Once you hit over ten moving objects, even if there\'s just one client, heavy lag kicks in and the whole thing goes to hell.

As a side note, if we do go with a 3rd party physics engine, it would be Novodex. Just wanted to make that clear.

Searching bodies: I don\'t see any reason why not. Certainly a better way to get ammo than running into the spinny shiny clip with sparkles flying around it. It\'s not like TTR was kid friendly to begin with anyways.

Lens flare: No. Just no. End of story.

Blood splat in face: Again no, as stated before. It\'s just worth reiterating.

HDR: Well, ya. I just hope you have a card that can handle it. If not, we do have fallbacks that work pretty well, even on my lowly Rage 128 (Note: My computer(s) will not be supported by TTR, so my saying something works on my computer should not be taken as an indication that I meet minimum system requirements).

Interaction with stuff: Um, ya. Sure, if you absolutely insist.

Keep the questions coming! Ideas from the community fuel development, unless we\'re in a bad mood and just say you\'re wrong.