Time & Resources
The Banished Vault - Design Diary 03
As discussed in previous design diaries, the game's model of rocket and orbital mechanics is meant to be very simple, with a core challenge in the rocket equation but otherwise nothing too finicky. The next major design problem comes in the form of resources, and the problems of time and space quickly followed.
Space fiction in general has trouble depicting scale. The distances, times, and masses involved are far beyond the human experience, and it makes a compelling setting to explore with our imaginations. Each depiction of space keeps a few goals front and center, and bends the details outside those goals to keep the story coherent and understandable. The goals in The Banished Vault are to travel around a solar system building structures, governed by a broad but realistic system of real math.
The nature of these goals means that doing anything will take a long time. In a normal game of resource gathering, time scales are measured in hours or days. For our timescale however, we need to measure months and years, to account for the distances to travel between planets.
This timescale affects an essential friction of a survival management game, resource scarcity. On this scale, resources are effectively infinite --- given a year, you could gather more water or iron than you could ever use, and there would still be effectively infinite water and iron remaining.
Resource infinity/scarcity can be subtly altered with how time is structured in the game. At an early point in the production, the game had a real-time clock. Once a ship was directed to move, it would do so immediately without stopping or synchronizing with anything else. This timescale proved difficult because of the functionally infinite resources. I sketched out different ways to depict that infinity: should resources be on spigots, where the player builds a little outlet and every n seconds, a resource pops out? Should resources have to be actively collected by the player, and after a certain amount of time the pool is refilled?
Some of my notes on realtime resource generation, infinity and scarcity
All those sketches had a crucial flaw; that in real-time the player can always wait things out. With the game proceeding regardless of the player's input, a lack of resources can always be circumvented by the player sitting and waiting. It doesn't provide any long-term challenge for the player, who knows that scarcity is always only in the short term. Additionally, because of the coarse resolution of the game, it proved hard to make the inputs or process of the actual resource production any more complex. Making fuel is basically turning water into fuel, and nothing more. So these solutions never reached past the paper design stage.
A separate but related concept I wanted to make sure the game reflected was resource locality, or essentially not having a resource dumped into a global pool accessible from anywhere in the solar system. If you harvested some iron on a moon, it's on that moon until you load it onto a ship and bring it somewhere else. The infinite and real-time designs began to dilute that concept, because after a certain point the player has enough resources to bring whatever they need to anywhere on the map.
Notes for turn based conversion
The solution comes in the form of time scarcity rather than resource or rate scarcity. The game was converted to turn based, and this easily allowed for a map clock without any real-time (for the player) pressure. Each turn is subdivided into actions, which govern most things the player does. To produce a resource, it costs an action. With your limited amount of actions you'll have to decide which resources you want to generate this turn, but the flow of resources never runs dry.
A turn system also allows for another concept the game needed, which was a overall pressure for the player in each solar system. A turn clock that counts down is a good game pressure without being a literal clock that is constantly ticking down, punishing the player for thinking. As initially counterintuitive as it might sound, a turn clock is a more realistic depiction of the narrative that actions take months and years. If a player is feeling the pressure of realtime, it feels more like a reflex game, even if that realtime represents huge amounts of game time. The header image above is a preview for events occurring when the clock reaches zero.
A turn/action system is also much more flexible and can be better integrated with the rest of the design. Since each turn is months/years, ship movement within a planetary system happens all within a turn. When a ship goes between planets, it must stop to wait one or more turns. A ship's travel time can be adequately expressed with turns, but not take up an inordinate amount of the player's time.
It seems obvious in hindsight, but this is how the design process works sometimes. You start an idea with some initial assumptions, explore around different ideas and variations, and end up in a place that seems like where you should have started. It's not always the case that ideas are continually improved from a starting point, sometimes concepts get thrown out entirely, or drastically simplified to better suit the entire design. In strategy design, it usually feels like a big wheel where you iterate a specific concept for a bit, move onto other areas of the design, and then have to reevaluate previous ideas so they work better in the future. You'll be able to see that revolving iteration in future design diaries as some of the ideas around actions and time go through more iteration.