some suggestions

[SgtH3nry3]

delerium10101 Wrote: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.

Too true, but exact location isn\'t that important.
Look at H&D2 for instance, the corpses lay on the same spot, but they always lay different on every other computer.

That isn\'t the point, the point is a dead body should lay at exactly the same position in spite of the way the corpse sit/stand/napping in the dirt or even hanging upside down.

Btw. 32 active bodies would make 64kb data.

delerium10101 Wrote: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.

Sound cool

delerium10101 Wrote: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.

Makes a very strong point.

delerium10101 Wrote:1.) 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.

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

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

4.) 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).

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

1.) Cool :tup:

2.) Thank God, I hate lens flare in games. Games shouldn\'t be cinematic.
Games are games, realistic games are realistic game, arcade games are arcade games.
A mix of them... well it TTR .

3.) God bless you I hate blood splats in your screens, too cinematic.

4.) atm. I have this 5200 Ultra but next year I\'ll have a X1800XT(PE) 512MB, maybe two of them!! :eek:

5.) W00h00!!!

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

Sure, I\'ll always have some suggestions for ya

Yours truly,
Henry.

[delerium10101]

Well, interesting catch here. Sure, we could say \"corpse is here\" but the precise arrangement is up to the client, however, collisions would get very screwy with the corpse (you will not be able to walk through corpses like it was nothing). And other things may collide with the corpse, like shrapnel. If the arrangement of the various limbs differs from computer to computer, we can\'t do things like that. The server says one thing, client A sees something different, and client B sees something different still. The server might say that shrapnel did hit client A, while client A sees the shrapnel blocked and client B sees some shrapnel hit and some miss. Personally, it\'s little details like using your fallen comrades as meat shields that add that extra immersive factor to a game, and unless client/server are in agreement, we can\'t do that without making people frustrated. And yes, collisions are in fact that accurate. No bounding box collisions for us, no no. If we do ragdoll, we will probably use the cheap cheat known as \"precomputed ragdoll\" which really means \"ooh, spiffy animation!\". Much *much* cheaper. A single byte transmitted once to indicate the animation, and no additional overhead beyond that.

And two X1800XTs? I am officially obligated to hate you.

[shift]

* shift slides his stinky feet in
Not to mention gameplay problems. Like \"Why am I being shooted if I\'m covered behind this corpse?\" or \"How the hell did that grenade bounced that weirdly next to the corpse there?\".

I really hope this rule extends to all the rest of features. I mean, what you see should be what all the rest see. No switchable grass, nor client-side dead bodies, and all the other effects you are working on. I prefer not to have a feature and have a fair gameplay experience than having more fancy eyecandy that just unbalances all or that I\'ll never use because I\'ll keep it switched off. Asuming you would allow to switch anything off.

[Big-Al]

i realized the other day that that cool indie grass probably won\'t be used much in a city map... :redface:

[delerium10101]

shift Wrote:* shift slides his stinky feet in
Not to mention gameplay problems. Like "Why am I being shooted if I\'m covered behind this corpse?" or "How the hell did that grenade bounced that weirdly next to the corpse there?".

I really hope this rule extends to all the rest of features. I mean, what you see should be what all the rest see. No switchable grass, nor client-side dead bodies, and all the other effects you are working on. I prefer not to have a feature and have a fair gameplay experience than having more fancy eyecandy that just unbalances all or that I\'ll never use because I\'ll keep it switched off. Asuming you would allow to switch anything off.

Exactly. It\'s happy gameplay problems like that that make multiplayer games so much fun to code.

Incidentally, most major gameplay affecting features probably can be toggled, but only on the server and only on game creation.

[tomcat ha]

bullets go through corpses. At least rifle bullets do.

[Big-Al]

not if they hit bone or a belt buckle?

[joeb]

I saw a video some time ago of an M1 Garand shooting straight thru 1 foot thick trees.. So I don\'t think a corpse would be much of a problem for it

[Big-Al]

I remember, when the nazis wanted to execute people and save on bullets, they would tie humans togeter in rows of 5 and the bullet would ofen kill them all... but sometimes the one at the back survived. a pretty horible way to exicute people. I believe this technic was used on jews etc...

[Delirium_]

thought that in the end they didn\'t even bother and just threw them in the ground and covered it.
but I know what you\'re saying is true too

strange that they, even when bullits are scarce, still bother to use them even when they have a multitude of ways to get rid of people fast.