@EmpirePhoenix
That is exactly what I do for all the objects that are not the one controlled by the user. Do you make the server authorative for the user moves or just let the client dictate where it is to the server?
I tried the authorative mode where by you store the moves performed since the last update from the server and then iterate over these until you receive an ack from the server for the new poisition. However, this means ‘rewinding’ the physics each tick, which I was having trouble doing.
I am now simply allowing the client to dictate his position to the server. If you can trust the client than this saves the rewind. I also read an interesting article on how they do it for mercenaries 2. I forget the address but you can google it. In this they also give client control to any physics object the user is interacting with (such as crashing into a wall). This works on the principle that it is still rare for many users interacting with the same items and the user perception is paramount (it is more important for the local physics to behave as the user expects than the server expects).
Matt
Hm I use only serveside logic, and a tickrate of 75ms, the client interpolates between the recived positions so you kinda look back 75+ping seconds. This actually feels kinda fluent when a little prediction is added (when pressing w the camera moves forward without waiting for the synch for example)
I'm going to use 2 physic world in client: one is sync with server (so it's 75+ping old) and one is what client's user expect to see.
when something external is applied in sync server (like an impule, or obj creation), the sinc world is copied over the asinc, and the asinc is stepped 75+ping (well it's just keep track of the asinc "time" before copy over and step to this time)
ok, sometimes user will see "teleporting" things, but only with high PING :)
If you can trust the client than this saves the rewind
nice for server, but very bad for the game.
IMHO Never ever trust a client.
if your is commercial, like mercenaries 2, this mean only maaaaaany cheater.
If your game is "for friends" this mean a little bug or a client closed in a bad way at the right time (and you know it means it will often happen) to garbage your server world
just my 5cent :)
Well the server dictates everything, client is only rendering and prediciton, however it is not using a physicspace for the prediction it is only continuing the send data (like rotation with x every second is repeatet untill told otherwise).
But there is no perfect concept actually. Since my game is mostly around spaceships and vehicles noone would expect a instant reaction so the 75 ms delay is acceptable in this case. While when running without vehicle the prediction hides most stuff good enough.
nice for server, but very bad for the game.
IMHO Never ever trust a client.
if your is commercial, like mercenaries 2, this mean only maaaaaany cheater.
If your game is “for friends” this mean a little bug or a client closed in a bad way at the right time (and you know it means it will often happen) to garbage your server world
The only drawback in trusting the client to send the correct position information is that they can cheat. In mercenaries this was not an issue as it is co-op play. When writing a game for friends it is also not an issue as they will not cheat any more than they would playing any other game for fun. There are also some basic checks you can do to prevent non-subtle cheating and I have to weigh up whether the time I can devote to the game (which is very limited) is better spent writing code to smoothly authorise with the server or on game play. I am currently choosing the later.
Whether you trust the client or not is completely irrelevant w.r.t junk data - you are no more likely to get junk from a 'trusted' client that an untrusted one.
@EmpirePhoenix
So if I understand right when you press W, for example, you will immediately move forward and then if you are in the wrong place the server will correct you? I think for most movement the physics is not relevant for the predicted time space (75ms-1 is not a lot really). The problem I had was when gravity played a significant part in my movement. If I did not predict this on the client then I snapped to the server a lot. I think I could of overcome it, but then thought I would develop the rest of the idea and revist if it became an issue.
The only drawback in trusting the client to send the correct position information is that they can cheat.
not only this. what happen, if two near(in physic) client say that they are overlapping like:
client A has radius 1 and is at 1,0,0
client B has radius 1 and is at 3,0,0
the move versus the centre (0,0,0), but in strange path, like they are drunk. Probably the clients will asinc from server (because lag) and consequently each others, at the next sync client A say it is at 0.5,0,0, and B is at 1,0,0... BANG! jbullet will do it's work and launch the two overlapping object away at a big speed...
no cheat, big problem.
Partial Solution: always do a test to see if the place is suitable. But is slow and actually you have to cheat with jbullet to do this (see the code above) and last but not least how you calculate the best position to place the object if the place is unsuitable?
A good idea (an I think good coding technique) is: solution before in object creation, and all situation where you can't do something else, but try to avoid as hell.
Try use only applyForce and applyImpulse to do all the rest.
I see your point and it is a good one. I think the key is that the client can be authorative when there is minimal interaction with other non player as, upon the point of contact (or near contact) on the clients machine both objects become authorative to the client and so there will be no syncing to an overlapped position. When it is 2 user controlled elements then it becomes more hazy and I guess both will have to bow to the server authority. Definitely something to think about though.