Working with Dr. McVey I was able to resolve several problems.
The first problem we tackled was the disconnection of a client because this was not working on the client or server side of the application. On the server side we found that when removing a client I had accidentally left the numClients–; call inside a loop so it was reducing the numClients to be negative and causing bounds errors. This fix was extremely helpful because it means that the server can be left online between tests and I can connect and disconnect freely instead of restarting it every test. kOn the client side the issue was more complex. Unity has the Destroy() function which takes in a GameObject and removes it from the scene. To remove the train of a disconnected client I was passing train.transform.parent.gameobject into Destroy(). Intuitively this would get the parent GameObject of the train and remove it from the scene. We would want this because when we destroy the train from the scene we do not only want to remove the train component we want to remove everything associated with that train everything attached to the parent object. However, what we found in testing is that every train on track shares a single parent GameObject so destroying that parent would destroy all the trains. To resolve this we simply moved one layer down and destroyed train.transform.gameobject.
The more valuable fix was the adjustments made to the spawning of trains. When we started trains were spawning in seemingly random positions at seemingly random times. The idea was that if Client A’s train is at position p1 moving to position p2 then on Client B’s side I should spawn Client A’s train at p2 to account for the time that passes between the location request and the spawning of the train. p2 is the difference between the current location of the train and the location of the waypoint that the train is targeting. p2 is changed every game tick. While testing we were able to find why this method was not working. the calculation of target – p1 = p2 does not do what I had assumed. Rather than placing a point somewhere between the target and the train for the train to head towards the calculation overshoots the target and slowly moves closer to the target, something like the photo below.
This photo helps to illustrate how the point to which the train is traveling is beyond the intended target but every game tick the train and p2 are updated. As we move closer and closer to the target p2 converges with the target and the train eventually reaches its destination.
Knowing that I could not use p2 to adjust for the time passing between messages sent from client to server to client, I decided to simplify and hope. Instead of sending where its going I send the exact location of the train and hope that the amount of time from send to recieve is not so long that the information is inaccurate. Thus far in testing I have found that the position is close enough to accurate that without extremely careful examination a person cannot tell the two simulations are different.
Leave a Reply