Lightspeed Communication Videos and Demo

Today is a very exciting day!  There are not one, but two videos for our fans.  They are both about how Lightspeed Communications work in Slower Than Light.  One is a two-and-a-half minute summary that quickly goes through the gameplay implications.  The second is an eighteen-minute live commentary as I actually played the demo, going over how I was doing everything.

Why did I make this second video?  Because I’m making the demo available on this website for download, so that both current and prospective backers and experiment with and experience how light-speed communications will work in Slower Than Light.

First, the summary video:

For those who want a deeper look, the demo video:

And finally, the link to the demo that you can download:

STL Lightspeed Communication Demo v0.1 Kickstarter Edition

This is a very exciting day for the Slower Than Light project, and I hope that you find the content here both exciting and informative.

3 thoughts on “Lightspeed Communication Videos and Demo”

  1. Overall, this is more or less what I expected, so looking good. 🙂 A couple of questions:

    1) Are relativistic (time) effects taken into account in the full game? It is reasonable to assume that all transmitted timestamps take this into account, so there would be an “absolute clock” that is shared among all colonies / ships for purposes of timestamps on messages, but there would be significant impacts on consumable usage for ships, for example.
    2) Are relativistic (mass) effects taken into account in the full game? Accelerating from 0 c to 0.1 c (as viewed from an “at rest” colony) takes far, far more delta-v than going from 0.8c to 0.9c.

    Given the nature of the game, I assume that both of these are part of the core gameplay (just not in this demo), but I figured I’d check. 🙂

    A couple of comments based on the second video (most of this is obvious stuff — just pointing it out for the record).

    There should be a provision to remove / suppress objects from the display manually. I’m assuming that in the full game that ships can suffer accidents and become “lost at sea”. At some point the player will realize that this is probably what happened (assuming the disaster is sudden enough to prevent the ship from sending an emergency transmission, or if the ship was simply out of range at the time the disaster struck), in which case the estimated location / ship icon needs to be removed to avoid misleading the player.

    There should be a mission order to transmit omnidirectional “pings” on a regular (yearly?) basis that request all receiving ships to send an immediate status update. The goal would be to dispatch a rescue / recovery / “what happened” mission along the same course as a lost ship to try to locate it. This type of mission would also be a good place to use the active sensor implementation that you’ve developed, as a fully derelict ship (vs. one that just lost propulsion) is going to be very hard to detect. Note that in the vast majority of cases this would require at least two missions — one, unmanned, to determine the current location of the ship and its velocity (which may have been changed by the disaster) that will almost certainly overshoot the target by a large margin, and a second on a slower trajectory that has enough delta-v to dock.

    There should be an “auto-optimize” button that, given a ship configuration, will produce a delta-v profile that results in it executing its mission in the shortest possible period of time, with the constraint that “At least X fuel must remain”. In the demo this wasn’t necessary — but, presumably in the full game there will be consumables that are expended based on mission duration, which means that the initial mass of the ship will vary depending on destination, and /that/ will mean that each mission’s fuel load has to be tailored individually. This will quickly become a pain, so…

    There should be a calculator that quickly and easily answers the question “This ship will be able to maintain contact with that colony (based on current configuration of both) at a distance of xxx light years”.

    An option should be provided to plot on the main map all current communication links — see the graphic in the last post in the blog for what it should look like.

    Objects that are currently out of communication should be highlighted on the main map — hovering over the object should reveal when (if) communication is expected to be re-established. This is going to be a complex piece of logic to implement, because it needs to take into account the movement of the out of communication object, /other/ moving objects (as they might move into a position to establish relay) and scheduled construction that impacts communication distance.

    It may be desirable to support “one way” communication (where the target can receive, but lacks sufficient power to respond) — this would allow the player to send commands “in the blind” to distant ships to try to respond to changing situations. The converse (you can receive messages from a source, but they cannot detect your response) should also be supported, although it would be less common.

    Along the same lines as the previous point, there should be a mechanism for a star system to send out a /very/ powerful omni-directional transmission as a system level project. In terms of content, think “ELF transmissions” to nuclear submarines — in terms of technology, think “shooting 10k tons of antimatter into a gas giant, shielded to prevent exposure until it gets deep into the core, igniting a secondary fusion reaction that consume much of the mass of the planet”. Obviously, there wouldn’t be much in the way of modulation possible in the message — either the player could define macros on how receivers respond to the message, or there would be fixed responses. The most obvious (& perhaps only logical) course of action for receivers would be:
    1) Colonies that aren’t currently in communication to focus exclusively on improving their communications until they are,
    2) Ships to abort their current mission and move towards the nearest object that they believe /is/ in communication with the homeworld (trying to reserve enough fuel to stop when they get there, but if that isn’t possible they will divert on a “one way” trajectory).

  2. To questions one and two, I forget if the demo handles any relativistic effects — if it does, I think it is only time dilation because of the impact that has on acceleration and deceleration rates. The full game implements vector SR for time, mass, and distance.

    Determining which objects are in communication and which are not is actually kind of tricky. You can have “estimated in communication”, in which I just figure out what the transmitter power is, what the estimated distance is, and assume all components are working, and I think that might be what you’re recommending. “Actually in communication”, which is to say that this ship or colony has made every expected check-in is a different metric, but helps detect failures in the system. Then, of course, there are all the unidirectional variations that you alluded to.

    Transmission in the blind is definitely an option in Slower Than Light — it almost has to be.

    I’m very conflicted on how to handle ships that have lost communications, especially during their cruise phase. Most ships are going to be going about as fast as is practical given the player’s technology (at least at the time they were launched.) Overtaking a ship that is clock 0.1c is not an easy task, even if you can detect it, and the timescale involved in doing so make the value of doing so questionable. An achievement, certainly, but it would be the rare corner case where it was both feasible and important enough to do.

  3. The tricky part of determining isn’t determining whether or not an object is currently in connection, based on its estimated position and the like — the hard part is determining when an object who isn’t currently in connection will be in the future, and (if so), when this is expected to occur.

    Now, you could simplify this calculation tremendously, by simply assuming that transmitters on colonies and the positions of objects will remain the same, so the only variable is either the position of the ship or the known construction queue of a colony, but… A projection based on that assumption would be incorrect far more frequently than it would be correct — it may not be worth implementing.

    A more accurate projection would need to take into account queued improvements in communications on other colonies and the movement of other ships — but at this point, you are coming very close to running a simulation of the underlying simulation, and that’s counterproductive (to say the least).

    I suspect that there isn’t a workable solution to this problem, but it is something to think about. 🙂

    I agree that locating and docking with derelict ships… Hard to do with realistic drive systems, due to massive delta-v problems. But… In most cases the ship that you are trying to intercept will be manned (and therefore relatively massive with a correspondingly low speed) while the interceptor / search ship will be unmanned (and much lighter, with a correspondingly higher maximum speed for a given amount of fuel). If the manned ship is traveling at 0.1 c, and the interceptor is capable of reaching 0.75 c (on a fly-by trajectory) then interception becomes feasible in a reasonable period of time. If the ship can achieve 0.75 c and still have enough delta-v left over to decelerate, then recovery is feasible (assuming that the target’s fuel reserves are still intact — hard dock the two vehicles, then use the rocket in the probe with the fuel from the ship to provide enough delta-v to get the ship back to a colony / slow it to the point where a manned ship can reasonably intercept and conduct salvage operations).

    Admittedly, how frequently the player would be willing to dedicate the time and resources conducting such an elaborate recovery operation is questionable — but if the manned ship sent back a message reporting first contact before contact was lost… 🙂

Leave a Reply