Monthly Archives: February 2014

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.

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.

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.

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.

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.

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.

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.