Objects in Space gives players a starship and sets them free in a galaxy to do as they will, becoming traders, pirates, bounty hunters, explorers, and more. It’s their decision what life they need, and what sort of complex ship they’ll have to build to do the job.

Gamasutra sat down with Leigh Harris (co-founder, lead designer, producer) and Elissa Harris (co-founder, designer, lead programmer) of developer Flat Earth Games to talk about creating intricate starship possibilities, drawing from submarines to create those ships, and the challenges that come from creating a universe of content for players to create lives out of.

The draw of the slow, colossal starship

Elissa: It was partly that while I have always been fond of sci-fi & space opera, and enjoyed space ships in games, but I was never that interested in flying Star Wars style fighters. My favorite movies always showed big, slow capital starships, and I hadn’t seen much of that in a game.

Leigh and I had often spoken about this, and it was when we began to think of merging ideas that we felt we had something pretty unique and cool on our hands. The idea of all the things we loved about a space trading game combined with a naval-ship-like combat system really appealed to us - a space game for those who aren’t action/twitch players, essentially.

Submarine sim inspirations

Elissa: I had been into submarines - ships, books, movies, and games - for many years. They’d always fascinated me. So, for me, it meant going back to my favorite sub sims such as Silent Hunter III and Dangerous Waters and asking the question: if you removed the restraint of simulating real hardware in a real environment, what design decisions could you make to keep the fun of this type of game, but smooth over the inherent rough edges of a submarine-like combat and stealth system?

In a sense, we were able to treat the numerous sub sims that had come before as prototypes - what could we take away from each game? Positive things, negative things? How did we find the control schemes, and what would we change given the chance?

On allowing the player to teach themselves about their complex ships

Leigh: At first, we were terrified of how complicated we'd made the ships. It was aesthetically pleasing in a lot of ways, but meant tutorializing was going to be a huge nightmare. We had to write an entire prologue chapter for the game as a standalone tutorial that we were hoping we wouldn't have to, and even then, we really only scratched the surface.

But at the end of the day, we realized that as long as players can move their ship around, dock and undock, letting them discover how it all works for themselves was one of the greatest parts of the game. So, we included in-game help in the form of messages from in-universe hardware manufacturers, advice from friendly NPCs, and an in-game Infopedia, and allowed players to get into it at their own pace.

It was very much designed as a sandbox, so keeping it open-format like that enhanced the game, rather than detracting from it. We still found outlier players who felt they were dropped into the deep end, but we compensated for that by really taking our time before ramping up the difficulty.

The game has time as a resource, so rather than have tutorial island, we have tutorial week, where the game takes it easy on players until an amount of time has passed, rather than until they've left some pre-defined borders.

Why allow players to build complex, custom controllers for Objects in Space

Elissa: It actually entirely came down a friend of mine saying “Hey, I just got an Arduino. You have to check these things out - you can hook it up to a computer. Want to help me code for it?”

I wanted to try interfacing with it just for fun, and the current project I had was Objects in Space. It made sense to play with that, as the idea of even my test console - some LEDs and a few buttons to fire torpedos, etc - was fun.

It wasn’t until myself, Jennifer Scheurle, and Leigh created a full on set of consoles for PAX Australia 2015 that we began to discuss ways to differentiate ourselves in a sea of indie games. We realized the fun of the hardware-interface idea and began work to formalize it as a game feature as we worked on a third set, which we'd end up taking all around the world to show off the game.

It did wonders for getting press attention and really gave players at expos and shows an idea of what we were trying to achieve aesthetically with the game, even if they never built their own setups at home.

Creating a galaxy-sized toy box

Leigh: One of our core pillars was player agency. We think of the game world as a toy box more than a rollercoaster ride. Options open up and up and up so that players can dip their toes into whichever aspects of the game they find most interesting.

There were no shortcuts here - no silver bullet to make it all work. We just had to refine and polish and refine and polish - which is a big part of why the game ended up taking five years to make instead of the two we'd hoped for.

We made three key decisions early on which opened a can of worms, but we were stubborn enough to see it through:

Open World - The amount of content and balancing required to make an open world game work CANNOT be overstated

Naturalistic - Time always moving forward and dialogue never repeating expanded our workload tenfold.

Submarine Simulator - Such a complicated set of systems and mechanics demanded similarly-complex economies to make them all work, which again expanded our workload massively.

There were heaps of other decisions which made the workload larger than it had to be, but all of them flowed from those three key pillars. We've learned more than we ever thought we would about the unpredictable ramifications of design decisions at a concept level.

The challenges of a universe of connected content

Leigh: More than we'd care to name. We used countless forms of 'maps' which helped us plan out the game world. Our 13 writers got to see a map with geography on the x dimension and time on the y dimension which we slowly populated *as* they wrote (Elissa and I were in charge of the major plot points which occurred, and revealed new ones each fortnight, as we and the writers all turned out a new side quest / storyline each fortnight as well).

So, writers could see the game world and its timeline unfold as they penned scripts for it, making characters arcs as unpredictable as they are in real life.

When we were done, those stories all got plotted out on a giant narrative map which allowed me to see whether there were any locations or in-game chunks of time which were devoid of content and ask writers to go and plug those gaps.

Similarly, the engineering section had layouts drawn for every module and set of components, and those were stacked against one another to ensure each one was meaningfully different in terms of stats and cost etc.

And finally, the rollout of the systems themselves in terms of how they were revealed to the player had to be carefully mapped out such that players who wanted to rush ahead and learn everything had that opportunity, while those who found the game overwhelming weren't pressured into learning too quickly.

Essentially, it came down to having more planning maps and diagrams explaining the flow of the game world than we've had to do on any previous title.

On using Early Access for Objects in Space

Elissa: It was very helpful. We’d done it before with a previous title, but it was a largely finished game, design-wise. So, I’m not sure we got that much out of Early Access for that. By contrast, Objects in Space is a very systems-driven game, and during our 6+ months in Early Access we got to work with players, streamline, and even in one case, redesign underlying systems to make the game more fun.

Even with our testers and the years spent on the game, when you get to see fresh eyes from players on your game, especially hundreds and hundreds of them, you really begin to see some of the things you can streamline about your design.

We wouldn’t have been able to do that without Early Access.