Hi,
Is it a good way to solve Client movement with messages like this in a server/client-based environment?
public int connectionID;
public Vector3f newPosition = new Vector3f();
public Vector3f viewDirection = new Vector3f();
public Vector3f walkDirection = new Vector3f();
I run on both server and clients the physics, so whenever a message like this arrives on the server, I will update the position of the CharacterControl I use for the players, and also the walkDirection. I get smooth results with that on localhost, but I think that doesn’t count
Can this be sufficient to avoid lags?
I know that this is a very hackable way to handle position updates, but I will add security checks like checking if the player walked to far over the time.
My second question is much more general:
Which generic approaches exist to handle different object-types and synchronize instances of them between server and clients? I don’t mean time-critical-properties of objects which change every frame or so, but atm I get to a point, where I have quite a few different kinds of objects with different properties I have to sync over network, things like i.e. points and nicknames of players. And I think it can’t be the best solution to have a NameChangeMessage, a PointChangedMessage, etc.
To your first question, you can see what it will kind of be like on real connections by adding a sleeping message listener on the client before you add any other listeners. Make sure it’s setup to receive all messages… and then just have it sleep for 250 to 500 ms or so… depending on what kind of connection you want to simulate.
Are your messages set to reliable or unreliable? (This equates to TCP or UDP.) Reliable messages have the problem that they all must arrive in order… so one slow message can stall the whole pipe for as long as two seconds and then you will get a rapid replay of all of the messages that were hanging. For unreliable, you may not see messages at all or they may come out of order. So if you are sending your messages reliably, you may want to augment the test listener mentioned above to randomly throw in longer delays every now and then.
Depending on what you are after, networking is kind of a tricky thing to get right. Other than for turn-based style games, without a clear plan things rapidly devolve into chaos.
Also, if the server is not authoritative then you probably don’t even want to bother to prevent cheating. It’s provably impossible to avoid if all clients are keeping their own game state… so you might as well just make cheating part of the game. Also, in the long run, the authoritative server turns out to be a side effect of a good network architecture… not just a feature/requirement. Once you start taming the chaos mentioned above, more and more things get moved to the server until, tada, it’s the authority again.
In this case, what seems simple is actually rapidly more complicated.
