Some musings regarding the network streaming component

[Mavor]

I just noticed that as it stands you need to mirror your scene graph on the client and the server if you want the stream to work properly...

I think that we need to have some way to specify the target scene of an entity coming in from the server to the client.. Perhaps the auto mode should work as it is now where you need to mirror the names of the client/server side scene graphs.. but have an advanced option where we can choose the target scene object we want to push the streaming entity too..

Finally, and importantly, is there a way to reverse the stream flow and have a separate stream running from the client to the server? I couldn't find anything about going the other direction in the documentation.

Thoughts?

[Irrelon]

@Mavor Client to server streaming is not planned as it just opens games up to cheating. If you want state updates for particular objects from client to server then you can send a network command and properly handle the receipt of that command on the server-side.

Imagine if we allowed client to server streaming... it wouldn't take much for a less-knowledgeable programmer to use the engine, see that feature and not think about the consequences, then blame the IGE for making their game totally open to hacks and abuse. I think it's much better to explicitly declare network commands to handle certain updates from the client to server such as a player's movement control being pressed so the server starts to move them etc.

Just my 2 cents on it really. Thoughts?

[Irrelon]

@Mavor Oh, and don't forget the issue of a potential loop situation flooding the network stream if the programmer gets it wrong. Server sends update, client updates and then sees it has updated so sends update to server, server updates and then sees it has updated and sends update to client... and on and on. Maybe I'm wrong but I think most web programmers are just getting to grips with how to make games, we don't want to throw them in the deep end with network issues like that to solve!

[Irrelon]

@Mavor Just wondering is there a reason you don't want to mirror the scenegraph on the client/server? If you think about it, if we don't mirror it then the server might execute logic out of step with how the programmer expects. With the scenegraph mirrored, logic (especially tick and behaviours) are called in the same order on client and server which allows a deterministic flow.

[Mavor]

Mainly not mirroring the scenegraph would simply be that I like to have different naming between client/server.. eg.. clientMainScene + serverMainScene vs mainScene.

Regarding the streaming... most games push from client to server on the player location. Without this, there is always a lag between player movement input and actual movement.. it makes the experience pretty bad. Sure, users can hack the crap out of it and have flying teleporting players, but this is a tradeoff that most of the AAA games have made. User experience is king.

[Irrelon]

@Mavor If you don't have the same IDs for client and server the stream won't know what entity it is talking about... (even scenes can be transformed so they are part of the stream too).

Re: Client to server streaming... gotta disagree there. No games that I can think of (esp. AAA) push entity positions / transforms back to server.

What they do is push control updates to the server such as "player 1 just pushed up on his controller, do what you will with that info". The server then receives that and applies a force or impulse to the player's entity. When the player lets go of the "up" control another message is sent to the server and then the server stops applying the force. The entity position is never sent up to the server... ever.

The lag you speak of can be mitigated with client prediction code. When the player presses up, the client starts to move the player BEFORE the server says it's ok so it gives the impression of instant response to movement. This is prediction. Then, the server sends data across the stream that basically "corrects" the client's prediction of the movement through interpolation from the predicted position to the actual authoritative position.

Client prediction is useful but not ideal. If you use it you will incur other REALLY complex issues with multiplayer such as dead reckoning.

If you test the model already in place you'll see that even with an 80ms round trip, the game appears very responsive. I'm using 100ms render latency in Starflight and with 20 people flying around and shooting at each other, I never felt like it was laggy based on my control input. Research shows that generally, players will not notice input lags of up to 200ms (but personally I can tell if it's higher than 100ms).

[goldfire]

I have to agree with Rob, here's a great article from Valve that I've always looked at as a great reference point about these issues: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

[Mavor]

Counter strike handles the actual positions of the player character client-side and then pushes to the server. You can notice games that dont do this very easy by the jittery movement you get in many places due to the server telling you things different then the client.

I'm 100% sure world of warcraft pushes player positional data from the client -> server, as there are many game hacks that allow for teleportation/infinite speed due to the fact that it is the client not the server that controls positional data. If the server controlled everything, basic client-side memory hacks wouldn't do anything.

[Irrelon]

@Mavor Thanks for the examples... that is actually quite shocking to me!

Regarding, "You can notice games that dont do this very easy by the jittery movement you get in many places due to the server telling you things different then the client." - But surely you wouldn't notice since the values are interpolated rather than just directly assigned? That's the whole point of the interpolation to smooth the movement across large jumps of updates.

[Mavor]

Interpolation usually works well but in some cases it fails, and the player notices it quite severely, especially when it is screwing around with their own movement input. :)

[Irrelon]

Interpolator is now active in the master branch. First commit, may contain bugs.