Sigma Tau: Networking & Structure
The code for Sigma Tau separates the World and the Bridge, making more intuitive and powerful networking for a bridge simulator, albeit different than typical games. The code for Sigma Tau, rather than having individual players connect to the world server, each ship is a single client which also acts as a server for the individual officers. I have a variety of reasons why I plan to do it this way.
1. Unix Philosophy
I am a firm believer of the Unix Philosophy . “Write programs that do one thing and do it well.” The World Server only knows a ship as a ship (not as several players) and it is a game like any typical game (where ships fly around and shoot each other) without caring about complications (like system power). The World Server does not need to be (much) more complicated than this (in theory it could be repurposed as a single pilot game). Also because of this clear separation of concerns, contributing to the code can be simpler.
2. No increased latency
Despite the fact that there are two layers of servers, latency is not necessarily going to be longer. The expectation is that, except in special cases, the Ship Server will be either on the same network as the Terminals or on the same computer as the World Server. Latency over LAN is insignificant when compared with over the network. The only time when Latency would be increased is if the Ship Server is hosted at a different place than either the World and the Terminals (an arrangement which would not even be possible with a typical single client, single server).
3. Reduced bandwidth
Having a separate World and Ship could greatly reduce bandwidth in the places it actually matters (and therefore reduce added latency).
One of the circumstances where bandwidth would be reduced (particularly on the server’s network) is when you two ships are playing together, each bridge in different places. If each bridge runs the Ship Server on their local network then the World Server only needs to send data to two connections, rather than sending ridiculous replications, and the ship server can send data to the Terminals without stressing the World Server’s network.
4. Simpler Terminal
The Sigma Tau Terminal will be a super-lightweight web-interface without much latency handing. The Terminal will basically only be an interface to change/view values on the Ship server (thruster power level, or scanner state, etc.) without predicting the effect from the changing of those values. This requires a low latency connection to the Ship Server (like LAN) but allows the Terminal to be super lightweight. I can only practically run a few instances of EE on my computer and, because my computer currently has a poor connection to the router, the other day I had to run only a single client!
5. Not meaningfully more complicated to use
There is no need for this to be any more complicated to set up. It would be trivial to have the main application allow you to start the World Server and a connected Ship Server (or multiple). And then players either navigate to the Ship Server’s URL in your browser or start another Ship Server to have another ship. Think of the Ship Server more like a player client in a typical game but with multiple Web GUI connections for controlling it.
This is a more full explanation of why this is how I am implementing the networking for Sigma Tau. If you have remarks or questions, I am happy to discuss.