3D chat

[Scott Richmond]

It just needs to be architected better. For example:

All objects have one parent owner, which can be actively swapped in and out. Eg, player controllers are almost exclusively owned by the client that spawned it. This client tells the server, and by extension everyone else, where it is. Similarly, objects such as barrels are most often owned by the server. Exceptions to this may be things like when collision occurs, the client temporarily takes control. Or maybe when a grav gun grabs an object.

 

This allows instantaneous feedback at the client machine and removes perceivable lag to areas where it isn't really noticeable (watching other players move).

 

Thats it on the most basic level. On top of that I guess you'd want the server to be running basic anti-cheating checks such as playerx.prevLoc - playerx.currentLoc != >10;. Or of course much more advanced stuff. And some simple animation smoothing on the client side to remove any correction jitter from server corrections.

 

Note: This was just off the top of my head, I've no doubt there are problems I've not thought of yet.

[Rick]

I think this would work if one of the issues could be solved. When setting position of things collisions still occur.

 

 

What if we make 2 controllers on the server side. Fixed joint them together on top of each other. One controller get it's position set from the clients position (and hence loses it's physics ability) while the other which has a fixed joint causing it to move with the first controller, can still react to physics events. That will give you the ability to have things show their effect on the player, but still not have the player get effected by the physics. But if you drop a barrel on a players head it'll react correctly for everyone. If a player runs into a barrel it'll move, but if something hits the player which would normally cause it to react via physics it wouldn't. So that would still need to be solved.

 

[EDIT]

Well if something should cause a client to apply physics the server would know about it because the collision would occur right? That message could be sent to the client and run locally on the client.

[Scott Richmond]

Too complex. The client should be performing physics on its own. The server should only ever be acting as the communication conduit, performing basic sanity checks, and owning the location of all the public objects.

[Josh]

It just needs to be architected better. For example:

All objects have one parent owner, which can be actively swapped in and out. Eg, player controllers are almost exclusively owned by the client that spawned it. This client tells the server, and by extension everyone else, where it is

That is exactly how I am handling it right now. The problem is that the interaction between the client-owned controllers and the server-owned drums is not as simple as it might seem. Still, if I can solve that, even with some problems remaining, it will be the best of what we want within the confines of the hardware.

[Scott Richmond]

Thats why I suggest being able to transfer ownership of those drums to the client that is interacting with them for the duration of the interaction. That way there is no lag for the client and everyone else (server, other clients) see a seemlessly working interaction, albeit delayed by the server delay, which is fine because that won't appear to them as delay.

[Rick]

Too complex. The client should be performing physics on its own. The server should only ever be acting as the communication conduit, performing basic sanity checks, and owning the location of all the public objects.

 

So how would the reaction of a player throwing a barrel at another player play out with this? Who owns the barrel? At what point does the ownership change to make it work on the client getting hit by the barrel that was thrown by the other client to give a proper reaction?

 

With the way I was describing the server would be able to recognize the collision and know the point of collision, force, etc. It would send that information to the client, who would then have that same force applied to give the proper reaction. The barrel would have the proper reaction on the server and update it's position to the clients accordingly because it has a working physics body for each client attached to the non working physics body that is getting it's position updated.

[Canardia]

When all clients run newton in precision mode, there shouldn't be any difference on the model positionings between clients. The server could sync the positions once every minute only!

The only thing the server needs to do actively is to handle the player positions, so that all surrounding physics objects which are moved by the players get the same physics forces in each client. It shouldn't be depending too much on the controller either, as some games might use completely custom physics bodies for the players.

[Scott Richmond]

So how would the reaction of a player throwing a barrel at another player play out with this? Who owns the barrel? At what point does the ownership change to make it work on the client getting hit by the barrel that was thrown by the other client to give a proper reaction?

 

With the way I was describing the server would be able to recognize the collision and know the point of collision, force, etc. It would send that information to the client, who would then have that same force applied to give the proper reaction. The barrel would have the proper reaction on the server and update it's position to the clients accordingly because it has a working physics body for each client attached to the non working physics body that is getting it's position updated.

With your method, one still experiences client<->server lag because the client has to wait on the server to tell it where the barrel is going. Thats not good enough.

 

To answer your first question - The client throws the barrel and then relinquishes control back to the server as it no longer is interacting with it. Then the server gives control to client2 when it catches and stops it.

 

Again, I didn't really think too much about this, so there are no doubt flaws. (eg, who applies the gravity?)

[Rick]

With your method, one still experiences client<->server lag because the client has to wait on the server to tell it where the barrel is going. Thats not good enough.

 

You are correct, but visually it wouldn't be noticed by the client. The position of the barrel on the client will always be behind the server. So when the server see's the collision and sends the details to the client, the client then gets the barrel position followed by the collision information to react on it's local controller. When the server gets the collision it sends a barrel position along with the force of the hit. The client then does the interpolation of the barrel and applies the force at the same time the barrel is at it's final "hit" position on the client side.

 

I think my nose just started bleeding

 

Now I want to try this out

[Josh]

To answer your first question - The client throws the barrel and then relinquishes control back to the server as it no longer is interacting with it. Then the server gives control to client2 when it catches and stops it.

Sure, but that's not even really a physics problem. The held object doesn't even have to be physically interactive. A much hard problem is if two players push a box in opposite directions.

 

Fortunately, the way I am setting this up allows you to make everything from pure server physics to client-controlled players. What I am aiming for is a means to have both with some glitchy interaction between players and physical objects.

[Canardia]

A much hard problem is if two players push a box in opposite directions.

That used to work fine in the Chat17 client when I pushed oildrums with wh1sp3r in opposite directions. Both were pushing it with the same force, and in the end the oildrum stopped between us.

[Rick]

A much hard problem is if two players push a box in opposite directions.

 

With the way I was describing this would work. The client is updating it's position on one controller on the server, and because the other is moving with it and has physics enabled it would push other physics objects. The same for the other client would do the same on the other side of the object. The object would go nowhere and that would be updated on the clients.

 

But I'm interested to see what you have going on Josh.

[Rick]

That used to work fine in the Chat17 client when I pushed oildrums with wh1sp3r in opposite directions. Both were pushing it with the same force, and in the end the oildrum stopped between us.

 

I can only guess that the controllers were controlled server side and had to client-side prediction. Once you introduce that it opens up other issues to deal with, but it's a door that has to be opened. Every modern (and even older, back to QuakeWorld http://en.wikipedia.org/wiki/Quake) networked game will have it.

 

 

http://developer.valvesoftware.com/wiki/Lag_compensation

This is also interesting for things like shooting. The server rewinds itself the amount of time it took for this client to get a message like shoot. By doing this the server can "see" the scene from the eyes of that client and would be able to tell if the client hit another client visually on their screen, which would make it a hit on the server as well.

[Scott Richmond]

You are correct, but visually it wouldn't be noticed by the client. The position of the barrel on the client will always be behind the server. So when the server see's the collision and sends the details to the client, the client then gets the barrel position followed by the collision information to react on it's local controller. When the server gets the collision it sends a barrel position along with the force of the hit. The client then does the interpolation of the barrel and applies the force at the same time the barrel is at it's final "hit" position on the client side.

 

I think my nose just started bleeding

 

Now I want to try this out

There will be noticable lag. Aren't you forgetting that there will be lag between you pushing the forward down when up against the barrel, and it actually moving. Between those two event the client has to ask the server what to do. The barrel will 'feel' really heavy because for a split second it'll have little to no movement. Not really acceptable.

 

Sure, but that's not even really a physics problem. The held object doesn't even have to be physically interactive. A much hard problem is if two players push a box in opposite directions.

Sure it does. If you pick up a barrel with a grav gun or just your avatars hands, for example, then you'll be moving it around and expecting it to be interacting with the environment.

RE: The two players acting on one object issue - Is it really that big an issue? Think about it. Physics isn't really a constant force in computer science - It is applied at every update. So say for example you have 2 players pushing a barrel into each other. In my mind I'd say the two players taking and giving back ownership in quick succession every time they update and realise they're colliding with the barrel. What a macro level this would cause and back and forth motion between the players. But in a live environment I'd expect you to see nothing as the forces match and nullify. If they were really big forces I'd probably expect to see some back and forth jitter as the forces over-coming each other.

 

Does that make sense? Am I wrong?

[Rick]

There will be noticable lag. Aren't you forgetting that there will be lag between you pushing the forward down when up against the barrel, and it actually moving.

 

You are correct, but I think that when neat little hiding tricks come into play. Look at something like Tomb Raider. When she's about to start moving she plays a small animation to get down into position and move. That 1/4 of a second would be enough time to do that.

 

It would cause issues if say you have the force (star wars style) and you wanted to push someone with your hand in a given direction. There would be a visual feedback delay, but again it might be avoided by animation trickery.

[Scott Richmond]

You are correct, but I think that when neat little hiding tricks come into play. Look at something like Tomb Raider. When she's about to start moving she plays a small animation to get down into position and move. That 1/4 of a second would be enough time to do that.

 

It would cause issues if say you have the force (star wars style) and you wanted to push someone with your hand in a given direction. There would be a visual feedback delay, but again it might be avoided by animation trickery.

Well there are ways to hide everything, but I'd like to think our goal here is to create a robust networking component. It is possible, Josh just needs to do the research and development. Which he is already in the middle of.

[Rick]

As true as that is, I also think there is a reason very few networked games use physics to a large degree. I think lag hiding tricks are inevitable. That's all client-side prediction is. You are hiding the input feedback lag.

[Scott Richmond]

I disagree. The only reason most games don't do it is quite simply because it not economically viable - It often has very little value-add. Its totally doable, someone just needs to sit down and really nut it out.

[Josh]

Can someone please create a server for testing?

[Rick]

For chat16 the movement seems instant, and the interaction with the barrels seems perfect.

[Josh]

For chat16 the movement seems instant, and the interaction with the barrels seems perfect.

What is your ping with the server you are on?

[Rick]

It was a server I created.

[Josh]

Yeah, of course that will be instant.

 

I am pretty well satisfied with the design now. Either the client or the server can create an entity and upload it to the network. If you have a fast-paced FPS or racing game, just let each client control their own player entity. If you have a physics-intensive game and are comfortable playing only on low-ping servers, let the server control everything. You might be able to create a controller on both the server and client ends, and do your own comparison, but I am not too worried about it. The point is that once you sync an entity, you can move it around, let physics move it, free it, and it will automatically be updated on all the clients, which is fantastic.

[Rick]

Yeah, of course that will be instant.

 

One of your versions wasn't that way. One of them I noticed a slight input lag on the controller even when I was the server.

 

Either way, do you have a final version of this for us to test out? Is this final chat version that?

[Josh]

I am cleaning the code up now. I haven't posted a client-controlled version yet.