Category Archives: Development

Development discussion and status.

Playing With Minds

March 28, 2014 John Brewer 5 Comments

Today I’m going to talk a bit about a concept that I’m not sure I’m going to add to Slower Than Light, but is currently on the table. This is one of those times I’d like to actively solicit feedback from my audience, because this feature could radically alter the gameplay experience of Slower Than Light one way or the other. That concept is Whole Brain Emulation, otherwise known as mind uploading.

The basic premise is that with sufficient resolution, we can (in theory) create a snapshot of a human brain, transfer that snapshot into a computer with sufficient processing capability, and the computer will simulate that person in all their mental and intellectual complexity.

Along with this concept comes a tremendous load of ethical, philosophical, legal, and moral implications, especially when you consider the related capabilities that might come along with it: mind manipulation, creating multiple copies of the same person’s mind, or most pertinently to our conversation: transmission of the snapshot.

If you have two colonies separated by some transmittable distance, mind uploading offers the potential to move “people” from one system to another at light-speed or very near light-speed, transfer them into a computer or a robotic frame, or perhaps even a human body, and allow them to act at their new location.

Being able to cheaply move population between colonies at the speed of light has tremendous implications for the political and colonial aspects of Slower Than Light. The technology does not, itself, violate the core stipulation of that game that the speed of light must be respected. The presence or absence of this technology, though, will shift the focus of this game and the role of spacecraft in it dramatically, so I’m thinking very long and very hard about whether to include it in release.

NOTE: From a technical coding perspective, implementing this form of transhumanism is just this side of trivial, given the architecture of the game’s data structures. This is strictly a design consideration.

Development

We Have Cleared The Tower

Image March 17, 2014 John Brewer 1 Comment

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.

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.

Development

Time After Time

March 7, 2014 John Brewer Leave a comment

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

Fixed Scenarios

March 6, 2014 John Brewer Leave a comment

The Inner Solar System abstract view as of this morning.

Yesterday I spent most of my development hours building out the file format and interpreter for fixed star systems. Until now the universe was entirely randomly generated. The most obvious use of this is being able to build the Sol system, and having the player begin their game on Earth. Starting on Earth grants a number of advantages for both the player and the designer.

First off, our local backyard is fairly well-known — our solar system is something that I suspect everybody interested in this game will have a familiarity with. If the first goal of the game is “Put a Colony on Another Planet” I might expect a player know that Mars is a relatively close-by planet. While some players might find other initial steps more enticing for their game, there’s a cultural inertia I can trust to help guide players towards certain targets, and certainly “Mars” carries considerably more emotional weight than “HD 164058 c.”

By launch I’d like to have the default map be an approximately real-world map, with local stars in the correct positions and have the RNG make a best-guess at planetary systems around those stars. That content will have to wait, though, while more pressing gameplay concerns are addressed.

I’ve thought about setting up a few well-known fictional star systems: Kerbol from Kerbal Space Program, Beta Caeli from Alien Legacy, The Verse from Firefly, or the Cyrannus system from Battlestar Galactica. Unfortunately, as published in apocrypha, STL can’t model the gravitation complexity of Cyrannus (I don’t have binary objects… yet), and I’m far from convinced that Firefly’s five-star hoedown is remotely gravitationally stable. Of course, all of these properties have intellectual properties rights associated with them, so including them as Easter Eggs would be problematic. That said, you might keep your eye out for references in the release version.

Development

Maneuver Selection

March 4, 2014 John Brewer 2 Comments

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.

Development

Local Clustering

March 3, 2014 John Brewer 3 Comments

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.

Development

Closer To A Video

February 19, 2014 John Brewer Leave a comment

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.

Development

Interface Elements

February 18, 2014 John Brewer Leave a comment

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.

Development

2D, 3D, and 4D

February 14, 2014 John Brewer 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.

A Hard-SciFi 4X Game