Slower Than Light is a very computationally intensive game. Most modern video games put their heaviest load on the graphics hardware, actually drawing pictures to the screen. STL does not; most of its computation power is being spent on the reasonably extensive amount of high-cost trigonometric and radical functions needed to solve orbital equations.
While the average gaming machine with a multi-core processor will run an average-sized map with a reasonable number of spacecraft without any issue, some gamers really thrive on running very high numbers of objects in their games. My background in writing clustered applications has made me think that I could bring that experience to Slower Than Light to enable those gamers with the inclination and available hardware to bring multiple machines to bear on their Slower Than Light games. The basic concept is that other machines on the gamer’s LAN would have node software installed on them that an active STL game could connect with to handle self-contained computational tasks.
I wouldn’t be building a distributed cluster system from scratch, but I would have to modify existing code to make it user-friendly enough for non-System Administrators to set it up easily, and to make the cluster nodes optimize for the fact they are probably not the mission application on the hardware they’re running on. Also, there is an intrinsic security concern with any distributed tasking software that I have ideas on how to handle appropriately, but again, making it user-friendly is the major challenge.
I estimate, based on previous experience, that it would probably be around 80-100 hours of effort to get this system installed in Slower Than Light, which is a considerable amount of the time budget I have laid out for this project. As we go forward, I’m going to be keeping my eyes open for whether or not this is a feature I should be including in the base game, or if it is something that can regulated to the expansions. Either way, I’m being sure to architect the code and install the hooks for a distributed system at some point in the future.
Um, the obvious solution to this is to /not run the simulation/ during accelerated time. After all, during a long interstellar voyage, there really isn’t any point in running a complex multi-body gravitational simulator of the voyage.
In fact, it is counterproductive to run the full gravitational simulation during an interstellar voyage. If you do, then the ship will be perturbed by the influence of nearby stars, resulting in a need for course corrections that the user can’t provide due to both accelerated time /and/ the speed-of-light delay. So, you’d have to abstract out the required mid-course corrections (either the Captain or the AI takes care of that for you), which means that that the displayed course will match the projected course exactly, so why not just advance the ship along the projected course in the first place? 🙂
Yeah, I know, you went through all the trouble of building a nice, robust, multi-body gravitational simulator, and turning it off for 99.9 % of the game seems like a waste of time, but…
Again, you’re bang-on correct, Mason — it makes very little sense to run the gravitational simulation during flight. All orbits in STL are stored as Keplerian orbital elements, allowing direct computation of the position of a body given a particular time index.
The bulk of the computational load that STL experiences is actually in its signal propagation system. To handle time delays, STL treats an event that creates observable information (such as a starship reporting status, a planet or ship changing orbit, an impact event, a supernova, a kitchen timer going off, whatever) as a point in 4-space with a function of signal strength over the EM spectrum. Various settlements and ships have the capacity to receive those signals, and translate them into reports that either get reported directly to the player’s observer or forwarded on. The practical upshot is that although I can take certain shortcuts that radically reduce the load in routing and calculating the bulk of these messages, certain types (such as those arriving in or departing an accelerating frame of reference) require considerably more computational power.
This issue become exponential as the number of ships and colonies in the game increases. I’ll be going into much greater depth on how the signal system and time delay work in a blog post later this week. Keep your eyes out for it!
Hmmm… I’ll wait until you post your update directly on topic, but I have a feeling that you are over simulating here.
The only place where it /matters/ when the message is received is the player(s) location (unless you have some really, really impressive AI going on, where one colony can autonomously provide assistance to another colony, for example), and it seems to me that the calculation could be done once (when the message is generated) and redone only when the player’s location moves (from a planet to a star ship, for example).
But I’ll wait for the communication update… 🙂