Author Topic: DEAD RECKONING ?  (Read 6672 times)


  • Guest
« on: December 24, 2005, 07:51:35 AM »
Hi guys,
well seems to have a little bit of problems after trying to reconstruct my game to let her act as a Multiplayer TPP shooter.

Well what is the problem :

i have managed how to do a simple 'dead reckoning' (or whatsoever) system while player shoots a bullet.
It looks generaly like that:

Client sends a packet that he shot a weapon nr X to the direction from location.
Server broadcasts that and every other client handles by its own the whole movement (so i don't flood the net).

The same for example with other stuffs (spawners / etc / etc)

I'm trying to resolve another thing that is Players movement.

Does anyone of you guys have some simple algo (even theoretical) that i should implement to resolve this issue?

 i see it like this:

- player1 hits a key to move (left,right,up,down)
- client1 sends packet:  im moving with speed from x,y,z to direction x1,y1,z1

+server broadcasts that data
+clients are doing the calculation (moving..)

-player1 stops pushing the keys
-sent info to server

+server broadcasts that
+clients are stopping the object

now, what if player1 will meantime change the direction - that should appear often, in tpp mplayer titles.

Do i get that right? or should i rethink some of the issues here?

Max players that would be allowed - 6.

Thanks guys.


  • Guest
« Reply #1 on: December 24, 2005, 07:53:15 AM »
Uh and one thing,,

should i do some player positions synchro every 2sec for example ?

I mean to broadcast to all of the players informations about their positions to keep their positions well synchronized?


  • Jr. Member
  • **
  • Posts: 51
  • Karma: 5
  • Daniel "Akano" Schemann
    • View Profile
    • SilentFuture - Gamedevelopment
« Reply #2 on: December 25, 2005, 09:08:37 AM »
Its not bad to send from time to time a position check package, that every client knows which the right position is.

If a player changes the direction, speed or something else the other clients have to know to calculate the right position you have to send it. There is no ohter way, else you have really bad jumps in your game when the pos sync was send and updatet.
Gamedevelopment: SilentFuture
Publishing: Gaming Kitty
MMO Development:


  • Not-a-newbie
  • *
  • Posts: 17
  • Karma: 1
    • View Profile
« Reply #3 on: January 07, 2006, 11:46:11 PM »
Another thing to keep in mind, is that timestamping can be useful. Especially in the situation of players moving.

If the client is gonna say "Hey i'm done moving NOW" each of the other clients can read the timestamp, and look at their current time.  If the timestamp is before the current time.. then you just need to move the character back by     (currenttime-timestamp) * PlayerMoveSpeed.    This will effectivly snap the player back into position of where the client who stopped moving, actually stopped moving.

Oliver Smith

  • Guest
« Reply #4 on: April 09, 2006, 08:47:13 AM »
You may want to read some of Brian Hook's articles.

Are you suggesting that when a player presses a key, the server is notified, but the client doesn't start to move until the server broadcasts the movement back to the player? If you are looking at a non-LAN game, that will be a very unpleasant game to play. Humans have a feedback expectation of under 250ms. And since modems are likely to push ping times up near that, then even slight packet loss is going to make your game feel unresponsive and laggy.

You might want to consider using the RakPeerInterface and having clients send updates to each other as a mesh as well as to the server for arbitration. But bear in mind that host updates are generally aggregated, so you will receive N updates per packet, whilst peer-to-peer each peer must send you a separate packet. The overhead of a packet is 20 bytes for the IPv4 header, 8 bytes for the UDP header, and at least 2 bytes for the Raknet packet. Thus if your update packets are relatively small, say 20 bytes, you would more than double the inbound bandwidth requirements of the application by sending updates peer-to-peer, and outbound traffic goes up relative to the number of peers.

The benefit of getting packets direct from the sender can be worth the bandwidth cost, but again at a price: not only must the players have a good connection to the server, but also to each other. Bob and Jim may both have 6ms ping times to the server, but if their respective ISPs don't have good peering, they may have 600ms ping times between themselves.

Oliver Smith

  • Full Member
  • ***
  • Posts: 173
  • Karma: 7
  • Oliver Smith
    • View Profile
    • Oliver's blog
« Reply #5 on: April 09, 2006, 05:59:51 PM »
Correct link: Book of Hook.