Thrust, Simulation, & Pacing
The Banished Vault Design Diary 02
In the previous designer diary, I broke down how the game simplifies rocket flight and orbital mechanics down to the most interesting problems for the player to solve. As the game developed however, I came full circle with an idea that added only a small amount of complexity, yet completely exploded the game's pacing and difficulty.
Saturn V Engine Test
The game is now at its prototype stage. Things are very simple: all that exists are locations, and links between them that cost delta-v / energy. A ship is basically just a mass, and can carry engines and fuel around. What I'm primarily determining at this point is whether this core idea is engaging, is assigning fuel and swapping engines to go various places an interesting puzzle to solve? It's hard to fully say, because the other pressures the game needs don't exist. You have to squint and pretend fuel isn't unlimited, but ultimately it does work. At this point I wanted to align the resolution of the game's simulation and add the other crucial component to rocket flight, which is thrust.
Simulation Resolution
Designers who make simulation games talk about something called resolution, which is a kind of 'depth' or 'complexity' that the simulation accounts for. Events, concepts, math, etc more detailed than this resolution are either ignored, represented using a random outcome, or combined with another concept. As an example, a game like Battletech will have many factors influencing one single outcome, whether a unit can hit another.
Situational modifiers for Battletech (2018)Â https://www.reddit.com/r/Battletechgame/comments/8gape7/hit_formula/
A game with a lower resolution and different priorities will a hit using a single die roll. Into The Breach is an abstract simulation of mech combat where single hits have no randomization at all.
The Banished Vault has a coarse resolution when it comes to orbital mechanics, which the previous design diary goes into. Even at this coarse resolution however, thrust is an important concept to represent. To explain simply: delta-v is energy is over time, and when spending months or years to travel the solar system, small engines can produce the necessary energy. Thrust is energy in an instant, or how hard an engine can push out of a gravity well. Without accounting for thrust, planets don't have a fully realized picture of their size and gravity.
From a mathematical point of view (at the game's resolution), thrust is much easier to implement and understand than delta-v. Engines have a thrust value, which is divided by the ship's total mass. If that value is greater than the planet's (simplified) gravity, then the ship is allowed to enter or leave the surface location of the planet. This simplified model sits neatly alongside the delta-v model, using only a few values with numerically simple output the player can work with.
Once this thrust model was implemented, the game was instantly worse. Much worse. This came down to one of those cases of "its hard to predict how complex games will feel until you play them", and how simple systems combined produce very complicated results. Sometimes that's exactly what we love about strategy games, and other times completely torches the pacing and player experience. So let's dig into why.
The effect of this thrust model was not on the math or player understanding, but on the time spent planning to move a ship in the solar system. Previously in the prototype, maneuvering around the solar system only accounted for delta-v. I had a scaffold system that required big engines to leave planets, which was now being replaced by the more complex thrust/mass/engine system.
Movement Calculations
Planning a maneuver is determining how much total fuel you'll need, and when to change engines to maximize your fuel usage. During this process, the player does one calculation, plus one, per engine change. To go from surface to orbit is a one step move, so zero engine changes and one calculation. To go from planet surface to moon surface is two engine changes:
Leaving surface (heavy engine) --- Travel to Moon orbit (efficient engine for fuel usage) --- Land on Moon (heavy engine again)
This is using a more updated math model, but the basic elements are present.
... which is three calculations. A calculation in these terms is looking at the game map, calculating the fuel needed (more on this later), then adding that to the running total of fuel for the entire maneuver. It sounds a bit heady written out, but this was a fun and interesting movement puzzle.
With the thrust raised to this level of resolution, now you have a second value to calculate. **The problem is, calculating the thrust changes the calculation of the delta-v value. **So firstly you do your delta-v calculations (I need N *Fuel for this maneuver), then following that you do your thrust calculations (this engine/mass combo does (or does not) satisfy the planet's requirement). You might then realize that for all the fuel you need to achieve the delta-v, *you no longer have enough thrust to leave the gravity well. You could make adjustments to the ship's cargo mass, but in either case you'd need to recalculate the delta-v a second time to make sure you have sufficient delta-v. Of course you might even have to do the whole cycle again, or indeed discover that for the intended maneuver there is no solution that fits the payload mass or fuel available. In my first test, the process took an actual 30 minutes to calculate a simple three step maneuver.
Pacing
The problem is one of pacing and mental calculation, as opposed to difficulty or resolution of the model. This is something that comes up in analog design a lot, a concept named a complexity budget. The budget refers to a self- (or market, genre, target audience) imposed restriction on how complex a game can be. This budget also affects the pacing of the game, and a poorly paced board game can feel like an actual chore. Many of the realistic space flight games I took inspiration from struggle in this aspect. But the issue is somewhat mitigated by the overall structure and duration of a tabletop game. In those games, which can last several hours, a player might plan only a handful of missions into space. Each mission is a rather grand affair, expending a lot of resources for a large and varied set of goals for the player.
A resource gathering video game needs a much different pacing. In The Banished Vault, a mission might only be to go to a moon and bring back a few bits of metal to your main outpost. It shouldn't take the player doing 30 minutes of napkin and computer assisted math to do something that simple. You can see the parallels to the problems I describe in the previous designer diary about trying to simply the math so an interesting game can stand upon it.
So within the day, the resolution-correct thrust was simplified. As the design currently stood, you loaded up your ship with a variety of mass and calculated the delta-v with fuel spent and engine efficiency. The engine also had a thrust value that simply had to exceed the planet's thrust requirement, and was otherwise unaffected. This maintained the spirit of thrust but did not foist complex and non-linear mathematical problems on the player to solve. Although by the time the first internal test of the game was prepared, I already had plans to modify the entire resolution of the game even further.