Balanced Complexity
The Banished Vault Design Diary 06
*This blog post describes the design iteration of the pacing and math complexity explored in the Thrust Simulation & Pacing entry. The game's math evolves and simplifies further, to settle on a nice middle ground that satisfies multiple goals.
In The Banished Vault, the player doing math can be a complicated subject. The math calculations the player is doing has an immediate effect on the pacing of performing missions and generally playing the game. The math needs to be complex enough to provide interesting friction and terrain for the player, but not so much that the player spends most of their time caught up in small details with large repercussions. As much as the game rewards planning and precision, it's a goal of mine to allow seat-of-your-pants and playing off estimates as well.
In the previous design diary on pacing, the thrust math was briefly made more complex, and then immediately simplified. I go into the reasons why there, and the details of how the pacing is affected and what a complexity budget is. This diary details the evolution of the math, in which the energy (corresponding to delta-v) equation has also been simplified and reduced in complexity.
The Energy Problem
Unlike thrust, which had its actual math changed to be less realistic, the math behind energy is still the rocket equation. What changes is how the mass in the equation is calculated, reducing the number of inputs and considerations the player has. To recap the system, the equation takes the ship's mass, the fuel for the maneuver, some variables related to the engine, and outputs an energy value that moves the ship around the solar system. The ship's mass was a sum of every piece of cargo (each with individual masses), the engine's mass, all the mass of the crew you had on board, and any extra fuel for future movement.
In any particular instant of time, this system makes sense and isn't too complex. The game adds up all the mass and does the calculation, the player just decides where to go and what to bring. The problem arises is that the player is still planning on what to load onto the ship, the energy range of the ship changes with every decision. If you've forgotten that you actually need to bring five units of iron instead of four, all the planning you've just done is thrown out.** Regardless if the maneuver is still possible, the player will have to check to be sure. **This kills the pacing.
Simple Mass
So a simplified version of the mass was implemented, like this: a ship has a single mass value. That value applies to the energy equation whether the inventory slots are full or empty. There's a set number of crew slots that function in the same way. While this is a pretty drastic (and unrealistic) change, it provides many benefits to the overall design.
The primary benefit is planning movement becomes much less fussy. Regardless of what you're bringing, you usually only need to calculate the movement once, or again if you need to change engines. If you change your mind on the cargo, or forget you actually needed to bring a few extra bits of whichever resource, the game is essentially forgiving you for that small mental mistake by not forcing you to recalculate the entire journey. This kind of soft punishment is something I want to generally avoid in favor of bigger and more bolder punishments the game has in store for you.
Another immediate benefit is allowing for a broader range of inefficiency that the player can deal with. Inefficiencies are good from a design point of view, they add some fun noise to the game. The fixed mass of the ship means that every empty slot is a visual reminder for the player that fuel is being wasted by sending a bigger ship than is necessary. But constructing a more appropriate ship is not a simple task, so the player will have to make do with what they have.
The broader benefits of making this kind of change is it frees up a huge amount of complexity budget for the rest of the design, allowing to actually bring a lot of other areas into a conceptual balance.
Balanced Complexity
Firstly, there are hard inventory limits now. Although this was probably going to be the case either way, it's now imperative to make the ships work. An engine takes up an entire inventory slot, and cannot be stacked, while resources can be stacked up to nine. Previously the incentive to play the game efficiently is in by the per-item mass cost, now the player is more directly space-limited. Bringing an engine means nine fewer of one type of resource. Multiple types of resources cannot stack, so you'll bring fewer of each.
Ships can also have a much greater variety in characteristics. With complex mass, there's too much for the player to account for, so ships themselves were simple and all the complexity was tied up in thinking of the impact each unit of resource had on the energy equation. Now ships can have varying inventory sizes, with a big cargo ship feeling big and heavy regardless of what you're doing with it. Some ships can hold a lot of crew but little cargo, or vice versa. Ships can also modify the engine's thrust, making the thrust system more realistic but maintaining simplicity --- a bigger ship requires more powerful engines to land on planets.
Ultimately, the simplified mass breaks a lot of the realistic rules that the game is originally premised on. But in aggregate, the complexity presented to the player is about the same, but overall richer, with clearer tradeoffs, inefficiencies, and possibilities.