Tag Archives: Spacetime

Development

Time After Time

Leave a comment
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.

Development

2D, 3D, and 4D

Leave a comment

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.