Today we’re into the second half of the Slower Than Light Kickstarter campaign. I always knew that this wasn’t going to be one of those Kickstarters that funds in seven hours, and today we are at 21% of the funding goal. We’re not out of this race yet, though — word is getting out, and there is clearly a trickle of funding even on days when nothing new is released. That said, we have a long way to go.
A lot of people have reached out to me to tell me how exciting they find Slower Than Light, and that they’re trying to get their friends interested in it as well. Thank you all for that! Keep posting to Facebook and Twitter and Reddit. Keep writing articles for your blogs and sites. Keep posting to your forums.
The relationship between mentions on blogs and forums and new backers joining the Kickstarter project is surprisingly direct. On average, a forum post brings in about $60. A blog post brings in about $35, as does a comment on a popular entry. A Reddit thread brings in about $130. A Facebook post brings in about $20, and remarkably, the average Google Plus post linking to the Slower Than Light Kickstarter brings in about $45.
I think it is important to point out that without the fan base of Slower Than Light, this project doesn’t have a chance. I reached out to everybody I knew who might be remotely interested, or know somebody interested on Day 1; I’m working hard to get Slower Than Light in front of the eyes of as many people as possible, knowing some fraction of them will be interested. That’s just marketing. You know things I don’t. You know small clusters of people who are interested in space, or strategy games, or just like novel game mechanics. You talk to people, you chat, you post, you can reach places I don’t even know to look for. I want you to know that doing so makes a real difference, often even more than your original pledge to the project.
It has been a fantastic 15 days so far, and I’m hoping the next 15 will be even better. Thank you all again for your support, and let’s get this thing done!
Today I’m going to talk a bit about a concept that I’m not sure I’m going to add to Slower Than Light, but is currently on the table. This is one of those times I’d like to actively solicit feedback from my audience, because this feature could radically alter the gameplay experience of Slower Than Light one way or the other. That concept is Whole Brain Emulation, otherwise known as mind uploading.
The basic premise is that with sufficient resolution, we can (in theory) create a snapshot of a human brain, transfer that snapshot into a computer with sufficient processing capability, and the computer will simulate that person in all their mental and intellectual complexity.
Along with this concept comes a tremendous load of ethical, philosophical, legal, and moral implications, especially when you consider the related capabilities that might come along with it: mind manipulation, creating multiple copies of the same person’s mind, or most pertinently to our conversation: transmission of the snapshot.
If you have two colonies separated by some transmittable distance, mind uploading offers the potential to move “people” from one system to another at light-speed or very near light-speed, transfer them into a computer or a robotic frame, or perhaps even a human body, and allow them to act at their new location.
Being able to cheaply move population between colonies at the speed of light has tremendous implications for the political and colonial aspects of Slower Than Light. The technology does not, itself, violate the core stipulation of that game that the speed of light must be respected. The presence or absence of this technology, though, will shift the focus of this game and the role of spacecraft in it dramatically, so I’m thinking very long and very hard about whether to include it in release.
NOTE: From a technical coding perspective, implementing this form of transhumanism is just this side of trivial, given the architecture of the game’s data structures. This is strictly a design consideration.
Recently I received a Kickstarter message from a potential backer asking me point-blank, what the heck my qualifications to run a software development project are and how I expected to handle 1,500 hours of work between April 15th and October 31st. I thought those were all great questions that I hadn’t really addressed in as many words yet, so I wanted to talk about it a bit here.
The first software project I worked on was an e-Commerce website in 1999-2000. At the time, I believe, it was the first printing website that offered on-demand proofs of invitations and business cards available on the Web. It has now evolved into einvite.com, although I suspect none of my code still runs on that site. It delivered on time on June 30, 2000.
The second software project I worked on was for the same company, and it was a ERM system to replace the DOS-based system the company had been using since long before I got there. For this project I had charge of one of the silos (shipping, specifically), and we delivered our component on-time, although the rest of the project dragged past my eventual departure from that organization in the autumn of 2003.
After that, I wouldn’t spend much time developing until 2007, when I became a sales engineer, and I began specializing in system integration for our customers. During that time, I lead many smaller, mission-specific projects. I can’t really discuss specifics of those projects, but I can say they were all tightly time-lined constrained, small-team projects. These projects were generally between seven days and six months, and would require integration with a number of client data systems, complex analysis of the data recovered from those systems, knowledge capture from users, and metric and result reporting to stakeholders. Of the ~25 projects I ran from 2007-2013, only two ran past their delivery dates, and both for very identifiable reasons.
That brings us to the quite recent past. When I was preparing for this Kickstarter, I needed to determine the amount of time I would need to complete the project. To that end, I compiled a list of must-have-to-launch features and tasks. I had already solved or routed around all the really intractable mathematical problems related to the game’s subject matter, so what I had left were a number of tasks that were at least analogous to things I had done in the past, if not direct knock-offs. Given my extreme comfort with C# and .NET, I was able to make pretty accurate estimates of the coding load. I talked with friends in the video game art community to get a sense of how much lead time an artist would need for the load I had. I worked out budgets and timelines and sources and all the minutiae that goes into a well-run development project.
My final total on development time was 1,142 hours. I multiplied that by 1.3 for overhead, unexpected delays, marketing tasks, etc. (I didn’t just trip over 1.3, by the way, I actually took the time to derive from my prior projects that I spend about 25% of my total work time on these overhead tasks. I don’t know if that’s high or low, but it is the observed value.) That took me up to 1,485 hours, so I rounded up to 1,500 hours.
Conventional reckoning would tell me that’s about 38 weeks of work at 40 hours a week. From April 15th to October 31st is about 27 weeks, which seems to present a shortfall of ten weeks. How do I intend to make up the difference?
I need to work about 56 hours a week to make October 1st under this plan. Normally, I work about 65 hours a week, so that isn’t a huge deal. I’m usually at my desk from 0830 to 2300 each work day, but an hour or two each day is lost to what I might generously call “unproductive activity.” I’m gifted with a considerable degree of focus, though, especially when I’m passionate about the work I’m doing. Over the 27 weeks of development, I’m looking at a predicted 1,755 hours of work if I don’t push myself too hard. In that time, I need to fit in and estimated 1,142 hours of development, which is actually just over 28 40-hour weeks.
There’s no question, I’m undertaking an ambitious schedule here, and I will be pushing hard to make my delivery date. I am not, however, making up numbers and diving in blind. My safety margin is nearly 35% of my total development time budget. I don’t have time to dilly-dally, but I do have the time to develop and deliver Slower Than Light on-schedule if the Kickstarter gets funded.
I have the time, the expertise, the knowledge, and the experience to delivery this project. I just really hope I can get the money.
Relativistic Kill Vehicles are a staple of space opera. The idea is simple — impart enough kinetic energy on your projectile, and make sure that energy carries it into something or someone you don’t like. Upon impact, the energy is shared between the projectile and the target, and much of it will go into remaking the target into a form you find more pleasing.
The interesting properties of RKVs all involve observation. Detecting an RKV is often very difficult — since terminal guidance is virtually impossible for them, they don’t expend a lot of thrust near the target, and therefore pretty much just reflect signals rather than emitting much of their own. Also, because they are traveling at a significant fraction of the speed of light, they have moved considerably by the time they are detected in a particular location.
Let’s take the scenario presented in yesterday’s video: six RKV’s enter the Sol system. Each is 1 ton traveling at 0.5c relative to Earth, their target. At that speed, relativistic effects are noticeable, but not extreme — the observed mass of each object from locations in the solar system is about 1.15 tons, not incredibly more than the projectile at rest. Let’s presume for the moment that Earth has the ability to detect an object the size of that projectile as far out as Neptune (~30 AU.) Since there’s minimal radiation from the object itself, let us also assume they’re using active radar to detect it. The fastest line of communication is a straight line, so let’s further presume that that radar station is on or near Earth.
The radar beam is pretty quick — it will bounce off the RKV as soon as it enters detection range, because it is always being sent out. The return, though, has to come from 30 AU all the way back to Earth at 1 AU, which will take about 4 hours. In those 4 hours, the RKV’s are closing in — when the radar return reaches each, the RKV’s are now 14.5 AU closer than they were — already inside Uranus’ orbit and only 4 hours from impacting Earth.
Because Earth is in the cross-hairs, this trend will continue until impact — the RKV will always be half the distance to Earth that the most recent returns say it is.
In the scenario depicted in the video, Earth attempts to defend itself by using Mass Drivers location on the Moon and in Australia to throw hunks of raw minerals in the path of the on-rushing RKV. Mass Drivers are fascinating devices of almost mythical ability depending on where you hear about them, but for our purposes, they accelerate heavy objects up to orbital velocities in a controlled way. They are essentially space guns that shoot big rocks.
Escape velocity for the Sol System from Earth’s orbit is about 41 km/s. There’s really no reason a Mass Driver on Earth would ever need to throw much harder than that, so I take 41 km/s to be the “muzzle velocity” of my defensive guns. I give them each a payload size of 100 tons, which is couple of cubic meters of some reasonably heavy metal they don’t care too much about. Each of these chunks of rock is bestowed with about 8.4 x 10^13 joules of energy. Some of it will be lost to gravity by the time they intercept the RKV, but for now let’s use that number.
Assuming the first shot comes off the drivers at T-4 hours exactly they will have made it to about 590,000 km by the time they reach the RKV and have a chance of hitting it. At this time, the RKV is four seconds from hitting Earth.
To save the Earth, the first ore packet would need to slow the RKV down to less than 1% of the speed of light. Unfortunately, even if it connects with the target, it will only have a fraction of the necessary energy. The blow would certainly change the RKV’s course, cause a different spot on Earth’s surface to be hit and reduce the final impact energy, but it wouldn’t come close to diverting it from slamming to the Earth with an energy release of about 3 gigatons.
Today I’m releasing a new video spot for Slower Than Light. I’ve been talking to a lot of my backers and potential backers, and I’ve gotten a lot of wonderful questions that I’ll continue addressing through the rest of the Kickstarter campaign. The biggest request I’ve had, though, is to put together something short that quickly communicates what the “plot” of Slower Than Light is, and something to get excited about.
I hadn’t really framed the question to myself that way before — because of the way the gameplay director takes the game in a different direction each time, I never really thought of the game in terms of plot. When I took a step back, though, I realized that the plot of the game is humanity attempting to evade extinction, which is what brought me to the Fermi Paradox.
The Fermi Paradox, in short, says that if it is possible to build an interstellar empire, it is very unlikely we are the first to do so. Despite that, we see no evidence of extraterrestrial races having done so, now or in the past. Therefore there should be, if not active alien civilizations, at least evidence of their existence in the form of megascale engineering and structured EM emissions that they once existed. To date, we have detected nothing that could be conclusively considered the work of intelligent life other than humans.
Besides the obvious implications for the question of if there is other intelligent life in the universe, Fermi’s Paradox has another thread — if no other race has achieved space colonization on a massive scale, and if progressing to our level of development common enough to happen in the span of two or three billion years with some reliability, then that implies there is some challenge we have not yet encountered that prevents these sorts of cultures from arising.
In many ways, Slower Than Light is an exploration of the Fermi Paradox. On the face of it, the game is simple: build colony ships, fling them to the stars, reach some arbitrary threshold and declare victory. It is the events that don’t fall into that pattern that make it interesting. Searching an empty cluster of stars and wondering why nobody ever came here before can be a chilling experience. Perhaps more chilling, though, might be finding evidence they were here, with more power and knowledge than we have, and failed to endure. What brought them low, and is it still a threat?
Commerce and influence in the world of Slower Than Light seem neigh-impossible at first glance. Shipping goods across interstellar distances is impractical for anything but the absolute most unique of artifacts. With the shortest trips between stars taking decades, and the extraordinary expense of safely moving humans between worlds, deploying armies would be utterly impractical; even if an ark carrying tens of thousands of troops was sent at fantastic expense, the destinations would have the time to develop a military-industrial complex almost from scratch before the attackers arrived to a defense custom-built to defend against them.
In Slower Than Light, the only ships to plow the void, with precious few exceptions, will be the unmanned probes gathering information on target starsystems, and the seedships carrying hundreds or thousands of colonists. How, then, can humanity’s scattered children have any impact on each other, enough to be a cohesive entity?
The only practically tradeable commodities are those that can be shipped at or near light-speed. The two major components of these will be Research and Power.
Research and technology is tradeable between worlds in Slower Than Light much as it is in other games in the 4X genre, albeit on a longer timescale. Colonies that can communicate with each other can share the fruits of their research programs, and give each other the information they need to replicate each other’s technology.
The other means of influencing other worlds is an outgrowth of technology. Any given star system will contain more raw resources than any colony is likely to use in the course of a game, and so the only limiting factor is if the energy available to harvest and convert those resources exists. Using extremely tightly confined beams of radiation, colonies can trade in energy itself.
Most obviously, newly-founded colonies will benefit from receiving beamed power from the homeworld. As the technology evolves, more power generation capacity and less loss in transfer will allow older, more mature settlements to give energy to the factions they want to help on other worlds, and help them maintain their influence over their colonies. As those colonies grow and generate their own surpluses, they then can send power on to other colonies, and the web of influence grows.
These two forms of trade interact in very different ways. Trading information is very straight-forward; presuming that each side actually wants what the other is offering, an exchange can be anything that both sides deem fair, although obviously lengthy back-and-forth negotiating will be exactly that.
Power transmission is a bit trickier. Every beam spreads as it travels, and so falls off exponentially as it travels further. Using ever-shorter frequencies of light, wider and therefore less divergent beams of power will help mitigate the power loss in transmission, but it is much more efficient to beam the power short distances rather than long distances.
The influence of power transmission is also dependent on where the power is being sent. There’s no benefit in beaming energy to a location if the power of the beam is less than they can get from their own star. Because of this, beamed power garners the most impact when used to influence settlements far from stars and other readily-accessible energy sources. Planets far from their parent stars and ships plying the interstellar void would be particularly dependent on the energy sent to them from other places, while planets orbiting close to their parent stars or those around particularly bright stars would be less moved by the offer of transmitted power.
Of course shipping very small objects on very faster courier will be an option, and might be necessary for certain objectives, but the real economy of the interstellar empire in Slower Than Light is built off of the faster courier there are or ever will be: photons.
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:
Today is the first of two parts talking about how the time delay in Slower Than Light works. Today I’m going to be writing about how signal strength and distance are abstracted, and how those create interesting interactions. Tomorrow there will be a video using one of STL’s prototypes, as well as a special surprise.
I know I’ve been accused of being obsessed with numbers in some places, and this post isn’t going to help that impression. If you’re just looking to see the mechanics in action, you can skip this post entirely and just watch tomorrow’s video when it goes up.
The basis of the way information flows around the galaxy in Slower Than Light is electromagnetic signals that move at light speed. Every signal in the game has two properties relevant to its propagation: the location it originated from, and its strength. Signals get weaker further from their source by the inverse square law. To make math easier for users (and developers…) the base signal strength of each transmitter is its strength at 1 light-year from the source. That is to say, if a transmitter on a colony or a starship has a stated strength of 100, the signal will have a strength of 100 one year later when it reaches 1 light-year’s distance from the source. It will have a strength of 25 when it reaches 2 light-years away a year after that. By the time it has traveled 10 light years, it will have only a strength of 1.
The second component of the system is a receiver. When a signal reaches a receiver, if the receiver’s sensitivity is lower than the signal’s strength, it can read and decode the message and either update its own database or forward the message along. Because transmitters and receivers can have different ratings on different planets, it is entirely possible for a colony to be able to hear another settlement, but not be heard by them.
Figures 1 and 2 show how this relationship works. Earth here has a 100 strength transmitter, while the colony 10 light-years away only has a 70 strength transmitter. Both have a 1 Sensitivity receiver. If Earth sends a message to the colony (Figure 1), the signal strength is reduced to 1 by the time it arrives(100 Strength divided by 10 lightyears squared), but since the colony has a receiver with a sensitivity of 1, it can receive the message from Earth. If the colony then attempts to respond, however, its message starts with a strength of 70, and by the time it reaches Earth it has been reduced to a strength of only 0.7, which is less than Earth’s receiver’s sensitivity, so Earth cannot hear the reply.
We resolve this communications gap with transceivers, devices that receive and re-transmit messages. In Figure 3, a relay spacecraft with a transceiver has been place between Earth and the colony. The relay has less transmitter strength than either Earth or the colony, but when it has the same receiver. When the colony’s signal reaches the relay, it has only degraded to 2.8 strength over the five light-years, so the relay can receive it. The relay then re-transmits the message to Earth with a strength of 50. Over the 5 light-years to Earth, the signal degrades down to a strength of 2, but is still easily receivable by the homeworld.
Deep Space Radar also uses the signal medium, but slightly differently. Each spacecraft in STL has a reflection percentage, an amount of signal strength it naturally reflects. Deep Space Radar sends out a powerful pulse, and every spacecraft reflects a small fraction of that pulse back, called the “return”. If the return is still strong enough to be detected when it returns to the point of origin, the target can be detected, and some information about its size, position and velocity can be derived.
Finally, the signal system is also used to collect information on other events that might be detected. Ships firing certain types of engines to accelerate and deccelerate might be visible to colonies in the same star system. Detonations of large weapons either planetside or in space would also be visible at some distance. Some natural sources produce signals that can interfere with near-by transmitters and receivers. Finally, most megaengineering projects will make a lot of noise on the electromagnetic spectrum.
Knowing how these signals move around the galaxy is important, but what does it mean for gameplay in STL? At a basic level, signals come in two flavors: Normal and Urgent. Normal signals are just regular updates on the locations of ships, the demographics of colonies, the status of production orders, that sort of thing. When they arrive, the player’s interface is silently updated to reflect the new information.
Urgent signals indicate something that happened that may require the player to intervene. For instance, when a new spacecraft is detected, that is considered an urgent signal. If the game were processing turns, it would immediately stop, give the player that message, and return them to the home screen to give orders.
When a new colony first makes contact, that is an urgent signal. If a distress signal is received, that is an urgent signal. All the normal messages you would expect a game to call your attention to are urgent signals.
Orders the player gives are also signals. If the player needs to order the colony from Figure 1 to build a spacecraft, the order will take 10 years to reach the colony, at which time construction will begin. If it took 2 years to build the spacecraft, the completion report would arrive back at Earth 12 years after that (22 years after the order was originally sent), and the orders for the ship would then take another 10 years to reach it from Earth, meaning that from the time construction was ordered to the time the ship received its orders would be 32 years. Of course, with STL it will be possible to send a mission along with the ship construction order so that it would only take 12 years for the ship to be built and assigned orders, but without foresight, the unwary can quickly find themselves with a many-decades-long construction process.
Each colony acts as a relay automatically, so if make sure all of your colonies can talk to at least one other colony when they’re founded, you’ll have a connected network of planets that can all send messages to each other. It might not be the most efficient method, though. In Figure 5, we have Earth attempting to communicate with Colony 3. Using the values for Earth, colonies, and relays given above, each world can send and receive messages to planets within 10 light-ears. Earth and Colony 3, though, are 16 light years apart. To get messages back and forth, they need to relay through Colony 1 and Colony 2, and each stage of that journey takes 10 years. Thus, when Colony 3 sends updates to Earth, they arrive 30 years later. With a string of relays across the void between Earth and Colony 3, that time could be cut down to a bit over 16 years.
Wow! That was nearly 1,300 words about the way signals work in Slower Than Light. If you read all that, congratulations! You’ve gone above and beyond. If you just skipped down here, don’t worry — I’ll be posting a video tomorrow demonstrating everything above to help make it clearer and help you see how these mechanics will actually play.
I had planned to write this blog entry today regardless, but it becomes particularly appropriate because today the TECHNOLOGY NAMING RIGHTS reward tier became exhausted. One of the questions I’ve gotten repeatedly, and with vigor, has been “Why aren’t there more rewards above the $30 level?”
That’s actually quite simple — there are, they just haven’t been opened yet. I’m not going to enumerate everything I have in store. partially because I want to maintain some surprise, but also because not all of them have been settled as things that won’t cost me more than the pledge amount.
One place I don’t intend to go with rewards is physical rewards — actually shipping materials to backers. Shipping goods costs about $6 for light objects (like T-Shirts, USB keys, etc.) domestically, and considerably more internationally. That’s atop the production cost of the item itself (again, usually $5-10). The actual handling is an issue, too — the hours of my time, or somebody else’s time, spent organizing, packing, labeling, checking, and transporting the rewards to a shipping company. Finally, some component of that would have to go to the game’s development budget. All told, shipping a T-Shirt on top of any given reward tier would add about $11-20 to that tier, depending on how big an order of T-Shirts I placed. I feel like that’s not a great value for my backers, although some might disagree. (If there is strong dissent on my opinion, let me know, and I will reconsider my position.)
Today I’m introducing the first post-launch Rewards Tier: IN-GAME PORTRAIT. An expansion of NAMING RIGHTS, the backer can provide an image of a person to be converted into a waist-up portrait that will always be associated with that person’s name in-game. As always, name and portrait both are subject to editorial review for appropriateness.
Tomorrow, we start a two-part series on the Time-Delay mechanics. Tomorrow’s post will be about how it works under the hood, and Friday’s will be about how it looks and plays in-game.
The $10 tier for Slower Than Light is “a downloadable DRM-free copy of Slower Than Light.” This has quite reasonably raised a number of questions about how DRM-free STL will be, both in Kickstarter-edition form, as well as the final sales configuration.
The plan for STL’s distribution is inspired by the way Arcen Games handles their games. At the very most, STL will use a license key that converts the demo version of the game to a full version. I am old enough to remember a time when I bought games off the shelf at an Electronics Boutique or a Babbages, drove home, installed it, and never had to connect to the internet once, let alone be always-on. I believe that that model is critical; I would much rather have a pirate playing my game than have a paying customer unable to.
Now, one of my goals with STL, if it funds, is to seek distribution via Steam. The way Steam works is to bind applications to a user account, and many people consider it a form of DRM in and of itself. Under these criteria, STL will be carrying DRM when purchased off Steam. It is my intention to begin selling STL outside of Steam’s purview as well, for users who, for whatever reason, choose not to use their service, and that version will be in the same configuration as the one Kickstarter backers receive.
In related news, there will likely be a Greenlight campaign launching when the Kickstarter tops $20,000 or 1,000 backers, whichever comes first.