For this final post I would like to take the time to address some things that I would have added or changed if I had the time to continue working on this project.
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.
Leave a Reply