Continuing in the series describing how 2pTD was built:
My initial approach to unit movement was to send out complete individual unit paths. These were basically driving directions for the units by defining a set of waypoints. This worked for simple cases, however, units needed to start taking different directions based on newly placed towers on the field. The old "driving" directions didn't include these detours so they'd need to be retransmitted to the client. The result was it actually was using more bandwidth than a dead-reckoning system would. The image on the right shows the test application where the full path was being sent to the client. The lines show the path of the unit (the purple circles).
So what is dead reckoning?
Think of dead-reckoning as simply describing where a something has been in the past. It takes a while to grasp the concept of this delayed system but it is the key to most online environments. The idea is to describe retroactively where a unit has been and to simply replay a units movement slightly delayed. Game development sites have great resources dealing with this problem which can become quite involved if a robust system is required. For this particular project I went bare-bones minimum.
Basically, approximately every second for every unit the last position (1 second ago) and the current position of the unit is sent to the client. The client then linearly interpolates between the two points over a one second period. This works for most constant movement. It starts to get a little 'weird' when units start varying their speed, which can be seen when you place towers which change the speed of the unit. The result is the client shows more of an average of the units movement, when in reality the units movement may be more erratic.
