Welcome to part 1 of the designer diary series for The Banished Vault! These entries will be exploring different aspects of the game in roughly the order that they were encountered during development. The first entry is about the very initial conception of the game, and solving a fundamental problem of how to create a complex game on top of a solar system that strives to be mathematically accurate.
I find solar systems infinitely fascinating. There’s so much potential for drama and, in game design terms, possibility space to provide interesting stories and challenges for the player. In the years since releasing Sun Dogs I’ve continued exploring how to represent solar systems, reducing the complexity so the dynamics produced can provide a foundation for an interesting game.
After going down many rabbit holes of Newtonian physics, patched conic approximation, and the shockingly cheap Gravity Engine asset, I would circle around an idea and inevitably fall back to a common conclusion: it’s too hard to have a complex game built upon realistic or semi-realistic orbital mechanics in a solar system.
The high watermark of orbital mechanics games is Kerbal Space Program, but in Kerbal, the game is the math and orbital mechanics. There are some ends to strive to, but really the meat of the game is learning and deploying the math. And it’s a lot of fun! It has ups and downs, but the puzzle of “get to that moon” is sufficiently complex and engaging to support an entire game. There isn’t much additional complexity beyond that.
Complexity
Making a complex game (from a ruleset point of view) is hard and hard to describe, but a pretty stable axiom is players should be able to make decisions with predictable outcomes. Usually, decisions also have relatively proportional outcomes: a big choice like choosing a faction has more impact in the game than moving a single piece on your board. Complexity can be achieved by asking the player to make many choices at the same time, or providing a cadence of small and big choices, or linking the choices together so the outcomes continually affect future decisions.
The problem with realistic or even almost-realistic orbital mechanics is that they are highly complex, and small changes in inputs (direction, launch time, spaceship mass, etc) can result in extremely different outcomes, sometimes by orders of magnitude. When you try to layer more ‘game’ complexity over this (factions, combat, resource gathering, etc), the butterfly effect of small changes in the orbital mechanics makes strategizing in the rest of the game a constantly moving target. It becomes paralyzing and hard to see the game as a whole, because you become mired in tiny yet unpredictable decisions.
Thinking several moves ahead is so much harder because even the smallest decision has very many potential outcomes. Making small adjustments to your plans in the strategy layer requires a complete recalculation of tactical plans in the orbital mechanics. None of what I’m saying means it’s impossible to make this kind of game, but it’s not the challenge I’m interested in tackling. These challenges still end up appearing in development, so you’ll get a great example of these in future designer diaries.
Inspiration came from boardgames about space flight. The objective complexity of a boardgame is generally lower, compared to a videogame, because the players themselves operate the game (subjectively it might feel much higher, to the player memorizing all of the rules). Boardgames like to divide space into big grids, and operate with small round numbers instead of more precise floats and fractions.
In Kerbal, the solar system is a continuous space, where an orbit can be in one of nearly infinite configurations. Every tiny jet of propulsion is calculated by the game, planets have elevation, and so on. A boardgame like Leaving Earth divides the solar system into big chunks, where each region is a big abstract space in the solar system. Each movement calculated by the game is significant, to another distinct region of space. Your ship is either on a planet surface or it isn’t.
It was while thinking about these abstractions I recalled the classic space graphic of the delta-v map or ‘subway map’ of the solar system.
A delta-v map for our solar system, by Ulysse Carion
Abstraction
Now the problem is reframed. Without a continuous space that a computer can depict but a player cannot easily internalize, an abstract solar system is born. In this abstract solar system, there are no complicated and finicky intercepts, orbits, or transfer windows. All astronomical bodies are organized in the tree structure of a delta-v map. The trunk is the sun’s gravity well, and each branch is a planet, and sub-branches for moons. Locations are meaningfully separated by the energy cost to move between them, not an actual distance.
The player doesn’t have to worry about any of the dozens of variables in rocket flight because for the narrative of the game, those things don’t matter. What is important is the mass, the engine, and the delta-v. Fewer, simpler, and meaningful choices allow the higher order decisions to be more complex and interesting.
The primary orbital mechanics puzzle the player contends with is a simplified rocket equation, the “the more fuel you have the more fuel you need” equation. In The Banished Vault, the player only sees the mass of their ship, their engine, and how much fuel they’re using. This outputs a number which needs to exceed the cost of their maneuver on the map, and that’s it.
This frees up mental energy for other more interesting constraints and decisions the game puts on the player. Did you harvest enough fuel, or would you rather leave something behind and save some fuel? Should you compromise with a smaller ship or build a more efficient engine? Should you do a one-way trip or budget for a two-way mission? For an exploration, resource gathering, and crew management game, these are the interesting questions that the game will ask you.