That being said, I was not very fond of the beginning of the course. It felt as though there was a lot of busy work that took away from time that I could have been working on my project. Had I not been caught up in readings and research I would have been able to implement more of the changes listed in my previous post. I understand that the readings were valuable but I wish they were learned at a different time. I would have loved to be able to meet the three times a week and always be sharing an update on my code or working with the class on a bug but most of the time that was not possible. I think it may be beneficial in the future to approach this capstone in the same way that philosophy and theology approach their thesis assignments; one semester long 2 credit course of research in fall and one semester long 2 credit course of working in the spring.

Although I have critiques I really enjoyed the overall experience especially because it gave me the opportunity to bond with many seniors I had not spent much time with prior to this course.

First is a simple change. I would change the deadlocking algorithm so that instead of deleting the train who caused deadlock I would send that train in reverse out of the section. In order to do that all I would have to do is my normal check for deadlock function and if that returns true then I would check for deadlock in the section I just left if I enter in reverse and if there is no deadlock there then change the section I am in to reverse and the client target to the first waypoint in the section, we will have already passed it. In the case that there would be deadlock if I went in reverse I would have to either make the code robust enough to keep checking for trains it can reverse out or make the client train disconnect since it cannot reverse out right away.

A larger change is the way that I connect the new clients to the server. What I currently do is load the track scene and on the first update I start trying to get the data from the server to initialize the track. This is inideal because it means that if any of the data is corrupted or the server does not respond in time all I can do is display a failed to connect message and tell the player to quit the game. The better way to do this is to set up the client before loading the track scene. This would mean contacting the server, receiving initial track data, saving that data to a file, loading the track scene, and reading the data from the file. The change to a file allows me to sit on the main menu and wait for responses from the server rather than sit in game and do the same. If the server fails to respond or gives unusable data I can prompt the user to try again instead of telling them to quit and reload.

I would also like to add spectator mode. This would be relatively easy to implement. All I would need to do is allow clients to join but if the server has reached a max amount of trains I set that client so that the only messages they can send to the server are disconnect messages. I would also set the spectators turnouts to all be disabled and would not display nor activate the train control UI. I would also edit the client initialization to only create a client train if the user was not a spectator. These changes would mean that a person could simulate the game like everyone else and would recieve the same updates as everyone else but would not be able to alter the track in any way.

I would also like to add a synchronization feature. This could be done by adding a new message type called REACHED. When your client train has reached a waypoint it will send a REACHED message to the server which would include its train id and the waypoint id it has reached. The same message will then be relayed to all the other clients and if on their end the train with that id is not currently targeting that waypoint id or the waypoint immediately following it the train would be teleported there. This would mean that each client would be the source of truth for its train and the server would communicate those true locations to the rest of the clients. If in testing I find that these messages come to frequently for the server to handle or that these messages cause other issues related to their frequency I have also considered a less frequent approach using the ENTER message. Instead of using REACHED we could use the ENTER message to ensure that when a given client enters a section all other clients also have them about to enter that section or in that section. These messages would be less frequent and easier to handle but would be less accurate to the true locations of the trains.

Finally I would like to add a bit of code to the server which would handle if a client’s game crashes unexpectedly. I have a whiteboard sketch of a possible way to handle this but it involves threads and I did not have enough time to debug a whole new thread as many strange issues come along with them. The juist of the solution is as follows. Start a timer for N seconds. After N seconds send a message to all clients who have not sent us a message since the timer started. If those clients respond with an empty message skip over them. If they respond with a message that is not empty add that message to a queue and skip over them. If they do not respond at all mark them for disconnection. After looping over all the clients who need to be checked we disconnect the clients who are marked for disconnection. After disconnecting the dead clients we handle all the queued messages. Finally mark the timer as complete, mark all clients as not responded yet, and kill the thread. The main thread will then see the timer is not going and will restart the timer creating a new thread to repeat the process after N seconds.

In code the solution proved to be as minimal as I would of liked and was implemented about two hours after the initial algorithm was developed. When a train enters a section the track checks if its the client’s train. If no nothing happens, if deadlock were to be coming the other client would have dealt with it already. If it is our client train then the track checks where the train will be exiting. For each of the potential sections that the train will exit to the track checks if it is occupied, if not then no deadlock. If the exit section is occupied then we check which way it is currently oriented, if it is not towards the endpoint that we are heading towards then no deadlock, that section will clear. If any section reaches the no deadlock threshold then we return happily but if all of them meet deadlocking criteria we remove the client train.

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.

Today I made a major breakthrough that should have been a minor one. Allow me to explain. During the flow of a game there are only 3 messages that a client knows it’s going to recieve, all three come from the server directly telling the client how to initialize the track. Because we know these are coming we can sit and wait for them. During client setup my code waits a set amount of time for each of these messages and if the amount of time is used up or a message is corrupt, they disconnect. This wait for the message method only works when we know a message should be on its way because waiting blocks all other code from executing. The way around this is to run an asyncListen() instead of the regular listen function. Asynchronous listening creates a second thread which blocks until a message is received. This means that I can listen all the time in the background while simulating the game at the same time. This function receives all of the other messages like when another train joins, a turnout is clicked, a train changes speed, ect. asyncListen() terminates just like a regular listen when it receives a message. In order to always be listening I simply had a bool listening and a function StartListening(). Every tick I check the listening variable and if the listening variable is set to false I call start listen which starts the asyncListen() and sets listening to true. What I forgot to do was set listening to false when the asyncListen() returned. So what was happening was the variable started as false then a listen started and it turned to true then never turned back to false so only the first message was received. After fixing this I now have some things working from client to server to client. For example, I can change a turnout on one and it changes on the other but a disconnect does not remove the train from the track for other clients.

On the client side I have the strange error that although Player B finishes the SpawnTrain() function which spawns in the Player A train, the actual train entity does not appear for several seconds and appears in the wrong location. I have no idea why the train waits to spawn even though the function completes. However, I do suspect that the issue of where the train is spawned is due to the funky math I do to spawn it. When Player B joins the game they notify the server. The server then sends all the available track data and asks player A where their train is. Player A then sends its location relative to the location of its current target waypoint along with the target waypoint index, section its in, and speed its traveling at. The relative location is found by taking the difference between the trains xy and the targets xy. Knowing this I assumed I could simply reverse the calculation, take the targets xy and add the difference xy and you get the trains location. In theory it should work but I believe I am mistaken in some assumption along the way. Another issue is that none of the messages that should be sent from one client to another seem to be getting there (except for the location request).

On the server while inspecting the missing messages issue I found that for some reason messages were being received and then sent to clients seemingly randomly. Sometimes messages were sent from A to A and B, sometimes from A to B or A to A, and sometimes from client A to no one. This bug was easy to track down and fix. To send my messages I use a function called SendToAllExcept which took an IpEndPoint object (a prewritten class from the .net.sockets library which represents IP Address Port pairs) and a message. The function would loop through all the clients connected to the server and if they were not the endpoint provided to the function the message would be sent to them. When analizing this function for issues I realized that it was overly complex. I did not need to exclude based on an endpoint because when receiving any message the server checks if it came from an existing client or not and stores which client sent it if they exist. This means that all I needed to compare in that function is the index of the client not the addresses. This is the better way to do it but when implementing this way I realized why the original implementation did not work. I was using: if (endpoint_a.Equals(endpoint_b)) instead of if( IpEndPoint.Equals(endpoint_a, endpoint_b). I believe the subtle difference meant that instead of using the .Equals to compare IpEndPoints I was using a .Equals which compared objects. After changing to the index send I was able to send the right messages to the right places but the messages still do not seem to be received or handled appropriately by the clients.