Tag Archives: .NET

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.

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.