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.