From: Stephen Ierodiaconou <steve_i83@ho...> - 2002-06-25 08:03:50
To avoid the player jerking (rubber banding ?) during a move the following
system might be employed.
This only concerns 2dclient
Each move action is split up into sections. Thus one path is made up into
smaller paths ( this is the case already I believe) and one section is sent
to the client. Now when the client receives this message it should move from
its start position to its end position in a time exactly calculated from the
turn-time of the game.
we have a move action in 2 pieces, action 1 tells player to move from A to B
and action 2 from B to C. If the server in theory takes 2 turns to get/send
the next move action , then with a turn-time of 500ms the client should know
to move the object from point A to B (start to end points in the 1st move
action) in exactly 1000ms. Therefore if the server takes longer than 2 turns
to get/send the 2nd message instead of the object in the 2dclient moving
straight past the end point of the 1st action (point B), then bouncing back
to it when the next message is received (which has point B as its start
location), the player will now simply wait at end point (point B) until next
action comes in.
For this to work better it might require the move actions path to be split
into quite a few pieces (I am not sure how many it is currently split into)
Thus , this system makes the client more dependant on the turn-time syncing
it more with the server.
Join the worlds largest e-mail service with MSN Hotmail.
From: Paul Chitescu <paulc-devel@nu...> - 2002-06-25 08:22:03
From: "Stephen Ierodiaconou" <steve_i83@...>
> To avoid the player jerking (rubber banding ?) during a move the following
> system might be employed.
The system is somehow in place except the timestamp sent by the server it's
not used since it's somehow coarse. Arianne it's not designed for real-time
The movement is NOT known to the client as a whole operation as it would
lead to cheating. Instead each object can have a speed attribute which
allows short term local prediction. Only when the server approaches the end
of a movement it adds a destination attribute that prevents the client from
getting past that point. A player won't get a significant advantage if s/he
sees the destination of a movement 1-2 turns in advance.
However, if a movement is aborted (by player action, hitting an obstacle,
etc.) the client will continue to move until it receives the appropriate
notification from server (position=x,y,z, no speed). At that time the object
will jump back to its real position. This is unavoidable, the only
workaround is to make turns shorter.
pchitescu@... http://pchitescu.null.ro/ ICQ:22641673
Any spammers will be painfully squeezed into /dev/null