We Have Cleared The Tower

What a remarkable weekend this has been.  The Kickstarter went up at 2100 EDT on Saturday, and since then I’ve been awash in communications and interest from people all over the world.  I intentionally reduced the copy on the Kickstarter page as much as I could to keep it from being overwhelming and to focus on the key points.  Keeping it concise has worked well, and I got a lot of positive feedback about that so far, but I know a lot of people just want more detail about mechanics, gameplay, and what distinguishes STL in an increasingly crowded field.

This week I’m going to be focusing on one popular question each day, and answering it in depth.  Today’s question is going to be about platform compatibility.  I want to talk a bit about why I’m only advertising the game as a Windows game, and why I’m hesitant to say it is for Linux and OSX  as well.

PLATFORMS

STL Running off my Linux box in an XMing Window.
STL Running off my Linux box in an XMing Window.

Slower Than Light is being developed on my Windows 7 workstation.  The development language is C#, which makes it a .NET Runtime.

I have gone to considerable lengths to make STL Mono-friendly.  Theoretically, it should run on Linux and Mac environments using Mono’s runtimes.  That is not really the question I need to address.

My greater problem is support.  I have a great deal of Windows experience, many machines to test on going all the way back to XP.  I am confident in my ability to support Slower Than Light on Windows.

I am shakier on Linux.  I have a few linux boxes at my disposal — a Debian box, an Ubuntu VM, and an ancient Slackware device.  My confidence in being able to support users running the Linux version of Slower Than Light is not really high — I’m sure most of the users I’d be supporting would know more about their environment that I do.  More to the point, while I could set up a server for each trouble ticket that came in, doing so would be prohibitively expensive from a time perspective; I simply wouldn’t have the time to work through many problems.

Mac is straight out — I don’t own a single OSX device, and I don’t have the budget to invest in a testing set.  I would be completely unable to test on, let alone support an OSX version.

So that’s the real crux of the platform issue for me — STL probably runs just fine on Linux and OSX, but I’m not willing to charge people for software that I can’t or won’t support.

Kickstarter Is Live!

This special announcement to say that our Kickstarter has gone live at https://www.kickstarter.com/projects/bronzite/slower-than-light.

If this is your first time at this blog, we update every weekday with new progress reports and information about STL and topics related to space exploration.

It is a long drive to our $30,000 goal, so please reach out to your friends and colleagues who are interested in space, 4X games, empire-building games, or world-building games, please let them know about our project.  If this Kickstart attempt fails, it is possible the project will die with it, so please do spread the word far and wide!

Nikolai Kardashev And His Marvelous Scale

Nikolai Kardashev is the deputy director of Russian Space Research Institute at the Russian Academy of Sciences.  Since the 1960’s, he has been responsible for a number of major contributions to SETI and related fields, both directly to the Soviet programs related to Extraterrestrial Intelligence, as well as IAU operations on that topic. He is perhaps most well-known for the Kardashev Scale, taken from a paper he published in 1964.

The theory behind the Kardashev Scale is that as a civilization becomes more technological advanced and extends its reach further and further out into the universe, its energy requirements will grow along with it.  Since all life as we know it must consume energy to interact with our universe, we can use the energy consumption of a civilization to judge its advancement.

Kardashev originally defined a Type I civilization as consuming the amount of energy humans used at the time of his paper’s publication (1964), or about 4 TW.  A Type II would be a civilization that consumed energy equal to its home star’s entire output (about 400,000,000,000,000 TW).  A Type III civilization would consume energy roughly equal to its own galaxy’s output.   The number of terawatts would be unwieldy to write here, so I’ll just say it is one-hundred billion times the energy consumption of a Type II (or ~ 4 x 1037 watts.)

In 1973, Carl Sagan suggested that the scale’s utility could be improved by adding intermediate values (providing fractional type values, such as a Type 1.1 civilization), and the scale would be revisited by Guillermo Lemarchand when he considered detectability of alien civilizations in 1992.  Lemarchand’s major contribution for our purposes was to move the rating for a Type 1 civilization up to the total solar energy impacting the Earth, which demotes modern-day human civilization to approximately a Type 0.72 civilization.

Slower Than Light uses the revised Kardashev scale as a mechanic for gauging what challenges the player is capable of handling.  The game will handle up to about a Type 2.0 civilization (indeed, achieving Type 2.0 would likely indicate a player victory, even in a sandbox mode.)  The gameplay director will use energy consumption as a metric to decide which of its library of crises are appropriate for the player.  For example, for Earth in 2014 (Type 0.72) an incoming large asteroid impact would be a planetary-scale crisis that needs to be dealt with successfully, or the civilization will collapse.  Humanity at Type 1.0 would probably be able to handle that situation without a strategic taxation of its resources.

A Type 1.0 crisis might be a solar flare of particularly aggressive demeanor approaching the Earth.  Such superflares have never been observed coming out of our sun, but have been found in similar stars.  They may be products of interactions with Hot Jupiters, or it may be possible for our sun to produce such a flare otherwise unprovoked.  Either way, stopping such a flare or recovering from its effects might be in the realm of a Type 1.0 civilization.

As the Type gets higher, what it takes to pose a challenge to that civilization gets more impressive.  At Type 1.5, a rogue planet set to alter Earth’s orbit (if not impact directly) would be a threat of epic magnitude, although by that time Earth would likely only be one of several planets humanity controls; losing it might no longer be an existential threat to the species.

Of course, certain crises carry the same weight no matter how advanced the civilization is technologically.  Political issues, such as revolutions and power struggles, will simply turn the technology humanity already has back on itself.  Biological or nanomechanical dangers have a minimum level of advancement required to become an issue, but can affect any civilization above that level.

Finally, there’s always the lurking possibility of an Outside Context Problem, usually in the form of a brushing encounter with another civilization much further up the scale than the base civilization.  Whether ETI will be making an appearance in STL is still an unresolved question, but such an encounter could easily be manifest as any of the crises listed above, or it could be an entirely different problem altogether.

 

Approval Granted

Kickstarter gave me the green light yesterday, so I now have a button I can push to launch the crowdfunding initiative for Slower Than Light.  Yay!

I’m cutting together a new video today, because as previously noted, the one I sent in with the approval package was not everything it could be.  I’ve decided the new video should really focus on the game experience — how the time-delay and communications blackouts can make this experience different from the standard space strategy experience.

Meanwhile, I spent much of last night reworking the flight planning system for space.  I finally got a working algorithm for converting orbital state vectors to orbital elements.  It doesn’t sound like much, but it means that I can be much more versatile about how the computer automatically plans out how to get from point A to point B.

 

Designing the Marathon: A Case Study

One idea I had for a video to promote Slower Than Light was to build the UESC Marathon from Bungie’s eponymous game.  In that game, Deimos has been converted into an interstellar sleeper ship that flies to Tau Ceti to start a colony there.  Marathon departs Mars in 2472 and arrives at Tau Ceti in 2773 (A 301-year voyage at around 4% the speed of light, or 12,000 km/s).  Since Slower Than Light supports converting small asteroids to starships, I wanted to actually build the Marathon in-game.

This was a great exercise in interface design, because it forced me to go through all the math that a player would have to go through to undertake a task like this, and what I need the software to be able to help them with.

To start with, I’ll presume the Marathon is using conventional rockets, not solar sails or anything like that.  Let’s assume that in launch configuration, Marathon has about the same mass as Deimos did originally.  With different propulsion types, how much of the asteroid has to be hollowed out just for fuel?

Tsiolkovsky’s rocket equation tells us that the thing that really matters is the exhaust velocity of our engines: how fast the reaction mass comes roaring out the back.  For H2/LOX engines in STL (like that Saturn V and other 20th-century rockets used), the exhaust velocity is about  4.17 km/s.  We multiply that times the natural log of the ratio of our total rocket weight to our empty rocket weight to get our delta-v.  Since we’re looking to accelerate up to 12,000 km/s and then back down, we need about 24,000 km/s of delta-v.

We divide 24,000km/s by our exhaust velocity to get 5,755.  We raise e to the 5,755th power to get 2.3 times 10 to 2499th as our fuel/mass ratio.  Using hydrogen and oxygen as fuel, we wouldn’t even be able to send an atom’s mass to Tau Ceti using a tank the size of Deimos.  We’ll need something with some more oomph to it.

Nuclear Pulse Propulsion, sometimes known as the Orion Drive, is frequently cited in literature as the most practical means of moving enormous masses around the solar system and galaxy at our current technology level.  Essentially the engine throws a small nuclear weapon out the back of the ship, detonates it, and lets the shockwave hit a pusher plate that drives the spacecraft forward.  Using this technology, it is theoretically possible to get an equivalent exhaust velocity of 1,000 km/s, 250 times more efficient than H2/LOX engines.

Run the numbers on those (e ^ (24,000 km/s / 1,000 km/s)) and you get 26,489,122,129 as your mass ratio.  Deimos has a mass of 1.4762 * 10^15 kilograms, or 1,476,200,000,000 tons.  To get Deimos to Tau Ceti using Nuclear Pulse Propulsion, we need to remove all but about 55 tons of that moon, and replace virtually its entire mass with nuclear bombs.

So what are our other options?  Antimatter is generally the cure-all for high-science woes.  If we built an antimatter rocket to take Deimos to Tau Ceti, how far and how fast would we need to go?  Well, the highest number I could find for a pure antimatter rocket was 100,000 km/s of exhaust velocity — now we’re talking!  I have no idea if that’s even kind of reasonable, but it is going to make our numbers much nicer, so we won’t ask too many questions (this blog post is already passing 500 words.)  At 100,000 km/s of exhaust velocity, we only need to raise e to 0.24, for a mass ratio of 1.271.  That’s bloody nothing!  We just need to replace 21.3% of Deimos’ mass with matter/antimatter fuel, and we’re off to the races with a tiny planetoid in tow.

Finding a pile of antimatter that weighs as much as a thousand aircraft carriers is left an exercise to the reader.

 

Submitted for Approval

Well, I was up until 0300, but I got the STL Kickstarter submitted for approval.  I wasn’t incredibly happy with the video, so I made sure I can change it before we actually launch, but I think it will be enough to pass muster with the Kickstarter reviewers.

I’ve been thinking about what I’m going to do to help convince backers that this project will complete.  My timeline is aggressive, to be say the least, and because the interface is currently the weak point on the game, it is difficult to really communicate via sheer gameplay videos how close Slower Than Light is to completion.

One idea I’ve had is to make v0.1 available from here and the Kickstarter page.  I’ve been trying it this morning, and it makes me cringe a bit at the thought of putting it in front of users; it does, however, demonstrate the light-speed propagation mechanic.  I don’t really want to devote any development time to making it more user friendly, because I do need to focus on both STL’s development along with the Kickstarter campaign itself.  I may cut together a tutorial video.

Approval Process

My project plan calls for the Kickstarter campaign to begin on Saturday, and I don’t have the video completed yet.  I’m very aware that a large fraction of Kickstarter backers will just watch the video and decide based on that whether or not they should fund my project.  I want to make STL’s video contain as much game play footage as possible, so that I can show what is different about this game.  Unfortunately, that’s not very easy.

Most of STL’s engine was built with unit and integration tests more focused on the mathematics and gameplay than the interface, so I find myself in the somewhat awkward position of trying to get funding for a game that doesn’t yet look very pretty.  I think today will be entirely dedicated to producing this video, rather than splitting my time between development and support work the way I normally do.  I need to give Kickstarter a few days to approve my project, which means to meet my project schedule, I need to get the video done today.  After all; if I can’t meet my schedule for the crowdfunding part of this project, how can I convince my backers that I can meet the schedule for development and release?

Time After Time

The Message Log Screen as of 7 March 2014.
The Message Log Screen as of 7 March 2014.

Yesterday’s development focus was on tracking time in its various incarnations and making STL more reasonable to play.

One big element I worked on is the “Slow Advance” and “Next Event” turn modes. With Slow Advance, the game runs forward at about 10 days/second on the Observed Universe screen. With “Next Event”, the universe just ticks forward as fast as it can go (which on my development machine is about 10,000 years/sec) until an event happens that requires the game to raise a notification to the player. At that point, the game stops and kicks the player to the message log so they can read about what happened, and then returns them to the Observed Universe screen.

In addition, the way the Universe advances has been enhanced to better support future additions to the code base, and to simply have better coding practices.  So many elements of STL are affected by the passage of time in such diverse ways that making sure that every object always gets the correct tick length for its location and frame of reference is critical.  Making sure that in-game objects have the opportunity to raise events that will arrest the “Next Event” progression once they reach the player’s in-universe observer is also of key importance.

I’m starting to get to the point where I need to be creating a lot more content and running validation tests to make sure that the physics engine is still returning correct values for everything that affects gameplay.  While I haven’t directly mucked with the mathematics, unit conversions and other subtle effects in modifications to seemingly unrelated code can have a surprising affect on these sorts of mechanisms.  All of that, however, can probably wait until after I get more done towards the Kickstarter drive.

Fixed Scenarios

The Inner Solar System abstract view as of this morning.
The Inner Solar System abstract view as of this morning.

Yesterday I spent most of my development hours building out the file format and interpreter for fixed star systems.  Until now the universe was entirely randomly generated.  The most obvious use of this is being able to build the Sol system, and having the player begin their game on Earth.  Starting on Earth grants a number of advantages for both the player and the designer.

First off, our local backyard is fairly well-known — our solar system is something that I suspect everybody interested in this game will have a familiarity with.  If the first goal of the game is “Put a Colony on Another Planet” I might expect a player know that Mars is a relatively close-by planet.  While some players might find other initial steps more enticing for their game, there’s a cultural inertia I can trust to help guide players towards certain targets, and certainly “Mars” carries considerably more emotional weight than “HD 164058 c.”

By launch I’d like to have the default map be an approximately real-world map, with local stars in the correct positions and have the RNG make a best-guess at planetary systems around those stars.  That content will have to wait, though, while more pressing gameplay concerns are addressed.

I’ve thought about setting up a few well-known fictional star systems: Kerbol from Kerbal Space Program, Beta Caeli from Alien Legacy, The Verse from Firefly, or the Cyrannus system from Battlestar Galactica.  Unfortunately, as published in apocrypha, STL can’t model the gravitation complexity of Cyrannus (I don’t have binary objects… yet), and I’m far from convinced that Firefly’s five-star hoedown is remotely gravitationally stable.  Of course, all of these properties have intellectual properties rights associated with them, so including them as Easter Eggs would be problematic.  That said, you might keep your eye out for references in the release version.

Public Exposure

Links to this site began hitting social media yesterday, and since then there’s been largely positive responses.  It has also been very interesting to see comments on sites like Reddit.  I expect to be directly responding to a number of concerns raised on those sites in the near future, since I suspect that comments there reflect a general sense of what our target audience is thinking as more information becomes available.

Right now the top comment on this thread is a concern as old as this game concept is: When the build time is so short as compared to movement time, won’t the game just become a frustration of doing a huge amount of local activity and waiting for a ship to cross the immense void to arrive at a distant star?

There is some truth there; the in-system game will proceed considerably faster than the out-system game.  The basic (although not atomic) element of game time is the day, and almost every star system will be less than a light-day across.  As a result, in-system play won’t be greatly affected by the signal-delay mechanics.  Most of the early game (at least when starting from a single Homeworld) will be in-system play as the player builds toward their first interstellar colony ship.

Eventually, though, the in-system game is going to get less interesting as the player’s home system becomes adequately developed to meet and exceed all of its productive requirements, and the challenges at home will take a back seat to the challenges in the stars.  At that point, the home system will more or less run itself — only construction of interstellar ships or mega-engineering projects will engage the player at home.  Reacting to events in the colonies will be the major gameplay of the later game, because some interstellar challenges only the Homeworld will have the resources to cope with.

Considerable thought has been put into not only how to overcome the technical and mathematical challenges of Slower Than Light, but also the game design challenges.  I am confident that the game upon release will keep the player engaged for the duration of their play experience.

To continue engaging, please like our Facebook page, follow our Twitter account, or add our Google+ page to your circles.