Maneuver Selection

Maneuver Selection Screen, 4 March 2014
Maneuver Selection Screen, 4 March 2014

One of the most significant interface challenges with Slower Than Light is helping players give maneuver orders to their spacecraft.  There are a number of trade-offs the player might make when selecting how to get from one celestial body to another, from the lowest delta-V route to the soonest arrival time.  Not only does the delta-V used have to be considered, but when the departure should be made; Hohmann transfers are generally very cheap, but the window to transfer to a sibling body only happens once or twice every orbit or two.  Meanwhile, a direct burn is often preposterously expensive, and many spacecraft simply wouldn’t be able to maintain thrust for that long.

The way STL handles this at the moment is it always presumes a Hohmann transfer, and list options for near-by targets (usually siblings of the spacecraft’s primary, the primary’s primary and its satellites) and has options for low and high orbit.  When departing a Gas Giant with many moons, this can end up being quite the extensive list.  Also, it makes interstellar transfers practically impossible, due to the immense length of time it would take two nearby stars to reach a Hohmann transfer configuration, and the considerably shorter time it would take for the spacecraft to actually make the transfer.  On the upside: extraordinarily low delta-V requirements to get to Alpha Centuari!

Obviously, the flight planner itself needs some work, but so does the selection mechanism.  Right now you just select the next destination orbit from a menu.  Besides only allowing the Hohmann transfers as indicated above, it prevents doing direct-insertion into other systems.  For instance, if I wanted to go from LEO to an orbit around Titan, the current system requires me to transfer into a circular orbit around Saturn before making a burn to move from Saturnian orbit to Titan.  For any given position of the three bodies in question, there is almost certainly an option that uses less delta-V that skips the injection into Saturn’s orbit.  As written now, that transfer isn’t an option for spacecraft in STL.

If I teach the flight planner how to calculate those orbits, though, it is going to start having huge numbers of maneuver options for each spacecraft.  That’s good, but I’m going to need to come up with a more sophisticated interface for selecting a destination.  That solution should probably be contextual, but having a searchable list of all achievable orbits would, I think, also be very useful.

Local Clustering

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.

Crowdfunding and Taxes

So I went to my accountant to do my taxes yesterday, because when you live in Massachusetts and you have a shiny new mortgage, you don’t want to mess up your taxes for that year.  After we worked through all my many failings as a person who makes optimal decisions based on the state and federal tax codes, we had a chance to chat about Slower Than Light.

I was a bit concerned about the prospect of raising money for this project from a tax perspective.  There is a fair amount written on the Internet about crowd funding and the like, and some of it covers how Kickstarter pledges are taxed.  That said, I am always a bit skeptical of information I read on the Internet, so I was grateful to talk to an actual professional regarding the issue.  We also talked a little bit about what, if any, corporate structures would make sense depending on how much money I raised and if I needed to bring more people onto the project.  It turns out there were no big pitfalls in my expected path, but there were a few close by that I could stumble into if I wasn’t careful.  As someone who has owed thousands of dollars in unexpected taxes because he did something dumb, I’m always a bit leery of such things.

On the upside, the management side of STL is going well, and I feel like I have a very good handle on how the financial side of the project is going to run if we manage to fund, and what records  I need to maintain the way I normally do, and which records I need to pay special attention to for tax purposes.

The Importance of Slower Than Light

Something I haven’t really talked about here yet is why I think Slower Than Light is an important project.  By a relatively traditional interpretation of my design document, I’m out of my mind.  Slower Than Light has huge complexity for its depth, and the complexity and depth are going to go up before I release.  So why am I even trying this, when by most modern game design principles, I’m building a train wreck?  Because mechanics that teach matter.

Slower Than Light is about trying to help the gamer get their arms around the complexity of human space exploration as we understand it today.  I am not trying to build some super-simulator that you can use to draft a proposal for a manned mission to Mars; I am trying to help give players a playground in which they can explore the issues involved at our current and near-future technology levels.

I learn by doing, and so I try to teach by doing as well.  For something like writing code or building plastic models, I can sit down with someone and teach them.  I can’t take my nephew out to the football field and launch a rocket to Venus.  You can grasp an understanding of what the challenges involved are with years of study, reading and watching and listening and attending and solving yourself, but few people have the time or interest in that level of research.  Rightly so; we have a few score years of life to live, and we have to be selective about how we spend them.

Slower Than Light aims to take what we know about the challenges of leaving Earth as a civilization, and providing the player with the tools to explore and gain an intuitive understanding of the difficulties involved and what resources we have to overcome those difficulties.  Knowing the math itself isn’t necessary; understanding the relationships between these obstacles is.

I deeply believe that if Humanity is to have a future, it lies in space.  I also believe that the largest obstacle to space exploration is that how it works is very mysterious to the vast majority of people on this planet.  I want Slower Than Light to be the tool that helps people really understand how difficult the task ahead of us is, and how we can make it happen even with those difficulties.  I strongly believe that people make rational decisions when they understand the choice they are making, and that off-world colonies are the rational decision for our species going forward.  The practical course of action, then, is to explain the choice as clearly, articulately, and completely as I can.  I know of no better way of explaining so complex a topic than a computer game.

So that’s what Slower Than Light is intended to be; a game, certainly, but a game that tries to educate and explain what space exploration will be, not in some Star Trek future, but tomorrow, in a year, in a hundred years.  Then, we can talk about whether we think it is a good idea.

Closer To A Video

This is the Spacecraft Editing Screen as it stands this morning.  The grid is drag-drop, although all the component art is just gray rectangles at the moment.  The abilities and properties readout is to the right.
This is the Spacecraft Editing Screen as it stands this morning. The grid is drag-drop, although all the component art is just gray rectangles at the moment. The abilities and properties readout is to the right.

Yesterday I got the component and ship designer up to their base level with the new interface elements.  I’m very excited — this is a major step forward toward getting the game into a demo-able state.  I hope to have a video in the beginning of March, probably a week or so before we start any crowdfunding efforts.

One of the big questions I’m waffling on right now is how to handle ship construction, and especially launch stack construction.  Right now the game treats every spacecraft as a unique flower — when you design it, it is built and launched just like that.  There’s no design that’s retained to copy to other ships.  That’s generally OK for the spacecraft themselves, but it also means that the launch stack for each ship needs to be constructed along with it, and that’s just not fun — the huge rockets and fuel requirements to launch the spacecraft is a fun problem to solve once, especially when you’re  lifting something particularly huge, but I’m thinking I want to allow you to declare a spacecraft as a launch stack, and then simply have the system use it to send up the other ships and stations you design by automatically mating them together.

I’m going to think about it some more, but how ship designs vs. ships vs. utility objects interact is a UI issue that I’m going to have to put some serious thought into.

Interface Elements

One thing I’ve felt particularly dirty about while working on Slower Than Light is the amount of code replication I have.  I’m not talking about code I wrote; in order to get the interface to look right, I’m having to implement a control system that rides on top of .NET and replicates a fair amount of the functionality of the standard System.Windows.Form controls.  I have Text Boxes and Listboxes and Buttons and Labels and so on, and a carefully crafted series of rectangles and flags to handle redrawing them only when they need to be redraw, and so forth.  All of these things are done, arguably better than I could hope to do them, by the extant controls.  So what am I doing?

Part of it is that my earlier working with Mono, the cross-platform .NET implementation, sometimes gave me considerable grief with windowing.  I could count on having draw surfaces and control input work more or less how I wanted them to, but sometimes the controls would act differently on Linux than they would on Windows, which makes one-man support for a cross-platform product a nightmare.

The other part of it is that I could not control the art and appearance quite the way I wanted with the basic controls.  Being able to draw controls is one thing, but being able to rotate and move them when I need to without converting out of System.Drawing.Drawing2D and then back in is really nice.  I am quite sure when that art and UI design take the main stage in a couple months, I will be very grateful for the investment I’m making now.

Research and Component Development

One thing I haven’t talked about much in any venue is the way that Slower Than Light handles technology research.  It adds an entire step to the creation of components that I think players will find gratifying, but poses a number of design and technical challenges to implement.  Let’s talk Science!

Basic vs. Applied Research

There are two different types of research players can assigned their science resources: Basic and Applied Research.  Basic Research is a semi-random system that allows the player to devote research to finding new branches of technology; ion engine technology, new fuel types, solar sails, and so forth.  The product of a successful Basic Research task is a new line of inquiry for Applied Research.

Applied Research is a more conventional leveling system.  In Applied Research, you choose to research a technology directly.  For example, you might allocate resources to researching fuel tanks.  On successful completion of that research task, your technology level in fuel tanks goes up one level.  What does that buy you?

Each Applied Research field has abilities and properties associated with  it.  These properties can be things like weight, capacity, thrust, power generation, and so on.  As you add levels to an Applied Research field, the values of these properties become more favorable.  For instance, in the above fuel tank example, as you research more levels of a fuel tank, the maximum capacity will go up and the dry mass (the weight of the tank when it is empty) will go down.

New Components and Technology Readiness Level

When a player is building spacecraft, they are made of components.  These components don’t pop into existence when your technology level gets sufficiently advanced to allow them; the actual engineering research needs to happen.

The development of a component is an explicitly ordered player action.  The player uses a component creation screen to lay out the capabilities of the component they want, based on the Applied Research levels they have.  Continuing our fuel tank example, a player might simply ask their engineers to create the best fuel tank they can by moving the sliders for capacity to the very highest it can go and the sliders for the dry mass to the very lowest it can go.  The engineers then go to work.

The technology is assigned a Technology Readiness Level (TRL) as the engineering team develops it.  Each set amount of time, depending on the complexity of the component, the engineering team makes a check to see how successful they have been.  If that are successful, the TRL goes up.  If they were unsuccessful, it does not.  If they were particularly unsuccessful, it goes down, indicating an unexpectedly dry line of development.  The TRL continues like this until it reaches TRL 7 – the prototype.  At this stage, the component becomes usable in player-built spacecraft, and the engineering team’s work stops.

The component’s development hasn’t ended, though — the component still has reliability penalties.  The player continues development by building and launching a spacecraft with the component being developed — literally flying the prototype.  If the component does not fail, the component is moved to TRL 8.  If it fails, it remains at TRL 7.  Once at TRL 8, the component is more reliable and available for future spacecraft, but it won’t be at its full potential until several missions are flown with the component, which put it firmly in TRL 9 — Flight Proven.

2D, 3D, and 4D

Slower Than Light is an interesting exercise in interface design, made more interesting by the fact that one of the major challenges I face is making a UI that will make it easy and fun for the user to navigate the complexities of the in-game universe.  One of the major decisions I had to make was if I was going to use Unity for the presentation layer, or a purely .NET solution, and that ultimately came down to whether I intended to use a 2D or 3D interface.

I admit, there was a bit of comfort-level consideration in my decision.   I was a fairly late adopter of .NET, having come from a culture in which bytecode was not “real code”, but I switched over when it became clear that it was not a fad, but rather how development was going to be done both at my company, and at many others around the world.  Even so, I’ve now had at least seven years using .NET, mostly C#, as my primary development platform.  I’m very comfortable working with it.

I started working with Unity in 2012.  Until then, I did most of my 3D programming in DirectX or XNA.  I had been working with Microsoft’s 3D pipeline since DirectX 7, when I gave lectures for WPI’s GDC on the technology, so again, it was a technology base I was very comfortable working with, and its structure and paradigm were familiar.  Unity embraced a structure that, to me, seemed very oriented around  particular types of games.  It made many things hilariously easier — 3D rendering was a breeze, and I could get a character walking around an environment inside 20 minutes — something that would take days in .NET.

That said, it seemed to have issues with data-driven games.  Anything that had static 2D screens, so common in 4X games, had to work around the fact that Unity expected to be constantly throwing out frames as fast as it could.  It seemed wasteful to be handling screens that way.

I hemmed and hawed about this for a year or more; I tried building interfaces in both environments, and after drafting more than a few prototypes, I ended up deciding that staying in .NET and going with a 2D interface was the way to go.  I think it is worthwhile to explain why.

The base coordinate system that STL operates in is four-dimensional; it represents objects and events in spacetime because it has to in order to be able to show a player what the universe looks like from their perspective.  Velocity (in special relativity) and gravity (in general relativity) transform space time coordinates in ways analogous to the way matrices transform 3D coordinates to display objects on a 2D display.  To get the math to work properly, I can’t really fudge the dimensions; I have to store everything as 3+1 spacetime.  Since my data already stores the 3D coordinates, that would seem to suggest I should render the game in 3D, rather than projecting from 4D into 3D and 3D into 2D.

If I rendered everything in 3D, it would be easier to communicate some concepts, and harder to communicate others.  For example, ship pathing looks more impressive in 3D, but it is actually doesn’t provide much useful information from a gameplay perspective; since distance and time are so far removed from each other in orbital mechanics (at least as compared to straight-line movement on a plane), the intuition a player has looking at an orbital path in 3D actually hurts their ability to judge what is going to happen, especially early on in the game.  I can provide numbers representing the pertinent details atop the 3D rendered display, but when I tried to do that, the interface just became a crowded, unsightly mess.  Perhaps a better UI designer than I could make an elegant solution, but I failed in that regard.

So ultimately I was left with the decision of whether I wanted to implement the presentation layer in .NET, and paying the price in the little bits of 3D I wanted, or implementing it in Unity, and paying the price for the bits of 2D I wanted.  When I plotted out a best-guess project plan for each possibility, .NET won handily, and the Unity option, in fact, would’ve threatened my timeline.

That said, there is a strong separation of functionality and interface in Slower Than Light, specifically because I needed to allow for either interface option.  As a result, it is possible that a 3D interface will come along one day, either from me or from somebody else if I release the engine for public or licensed use.

Starting the Drive to Launch

Welcome to slowerthanlightgame.com!  We finally have a proper domain set up for this project, rather than piggybacking off my other domains.

Right now my project plan calls for a game release in October 2014, with a possible Beta in starting in July.  In early March I’m expecting to run a Kickstarter campaign to raise the funding I need to get us to October, as well as to finance the art design needed to really make the game look the best it can to bring more to our players.

I’m looking forward to this project, and I hope you are, too.