[Sigma Tau] Dev Log 01
I have decided to switch back to D for the parts of the code I was using Haskell. Using Haskell was a bit of a test. (The 3D screenshot I shared originally was using the Haskell code.) The Terminal is still, of course, using JS/HTML.
In the last couple week I have been nailing down the networking structure code. The networking for Sigma Tau, has had, probably, the most experimenting.
Sigma Tau does networking, perhaps, quite uniquely. I am becoming very happy with how it is forming. It both separates out the networking, while also not distancing from it; I think it is quite easy to work with.
The Ship in Sigma Tau is split up into components. [1] A component might be a laser, or a thruster, a sensor, or a flight computer. Every component is a class and a subclass of Component. [2] Most of the time, a component makes changes to the world (spawning a missile or laser, or sending a communication) directly, for some components (like thrusters) the ship needs to do some of the logic to get the expected behavior. There are many varying types of components, and not every ship has the same types.
As I mentioned in the core concepts, in Sigma Tau there is not a limited set of systems with a narrow variance of functionality. All the different components of a ship are generalized as “components” and the ship has an array of them. The only difference between a thruster and a laser to the ship is that one happens to call functions to spawn lasers and the other to move the ship (unless a certain type of laser actually has kick-back?...) To make a new component, just make a new component subclass… Components are handled quite similar to how Unity has objects (Component is the equivalent of MonoBehavior).
Communication with the Terminals (player screens) is done through ports. A port is basically a value (or values) which is networked to the Terminals. A port might be the throttle of the thruster, or the view of a radar. Ports are the communication layer for the components. There is not a 1 to 1 connection between ports and components. Most thruster types will use the same port type, and some components might have multiple ports. A component creates the ports it wants to use, and uses the port to manage the values shared with the terminals (e.g.). In the terminal, a GUI widget is basically just a user interface for a port or ports (e.g. a slider for the impulse of a thruster (which uses the “Wire” port), or display for the Radar port, etc).
I linked references to places in my code. Some parts of the code are still very temporary, just hacked into place to be able to test the code I am working on. I would love feedback on the actual code, especially in terms readability/understandably for someone other than myself. The code for the Ports is quite complex, and uses a lot of D's compile-time logic magic. The code for the Components should be quite simple (and understandable to anyone familiar with C style language (C, C++, Java, C#, etc.)). The most confusing part of a component is the declaration of the ports it has, it is just using some D magic to define an array of the ports for the ship to use to send to the terminals. (D uses the ! as a binary operator for templates (as a unary operator it is still not), RadarPort!true or RadarPort!(true) is the equivalent of RadarPort<true> in C++)