When Adding a Rule, What Else Gets Added?
In Death Stranding, the more cargo Sam carries, the higher it tends to stack. When he passes through a low doorway, any cargo extending above the frame can be knocked off and fall to the ground.
The game could have handled this differently: if the cargo stack is too high, simply prevent the player from passing through.
Both rules seem to communicate the same thing: you are carrying too much for this space. But in practice, they do very different things.
Under the current rule, the doorway remains passable. The player can walk through normally and accept the risk of losing cargo, or crouch and trade speed for keeping the cargo secure. In other words, the cargo stack changes the cost of using the route.
If the rule instead said, “You cannot pass when your cargo is too high,” it would change something else entirely:
Whether that route exists as an option at all.
That may seem like a small difference, but it determines which other systems and content now have to start accounting for the player’s carrying state.
How Does a Simple Rule Become Complicated?
Suppose we really did establish this rule: if the cargo stack is higher than the doorway, the player cannot pass through.
The check itself might be easy to implement. It might even be simpler than handling collisions between cargo and the doorframe. But the costs that are easiest to underestimate do not necessarily come from implementation.
The rule would first begin to affect content production.
Level designers would need to know which doorway heights allow which cargo stacks through, and might start using that distinction when designing routes. Mission flows might begin to depend on the player being able to traverse a particular route in a certain carrying state. QA might need to validate routes with different cargo-stack heights.
At that point, “cargo height determines whether this doorway is passable” is no longer just a parameter in the character system. It has become an assumption that a body of content depends on.
Changing it later becomes a very different proposition.
Suppose halfway through production we change cargo dimensions, doorway dimensions, or the player’s traversal capabilities. The feature-level change might be small, but we would still need to ask whether existing levels remain valid. Do doorways that once distinguished between two routes still serve that purpose? Have some mission paths changed? Do existing test cases need to be validated again?
The difficult part is no longer just the rule itself. It is how many other things have begun to depend on it.
That is how a rule that is cheap to implement can eventually become an expensive rule.
There is a similar example elsewhere in Death Stranding.
In a GDC 2021 AI postmortem (https://www.youtube.com/watch?v=yqZE5O8VPAU ), Kojima Productions described several requirements for MULE behavior: MULEs needed to pursue the player and steal cargo; they should be able to follow the player into places the player could reach; and they needed to retrieve cargo dropped across the terrain.
That sounds like a relatively simple AI behavior requirement. But Death Stranding has extremely complex terrain, and players can alter traversal through structures they build in the world. The requirement therefore expands: AI has to handle difficult terrain, support long-range pathfinding, and deal with player-placed traversal structures.
Get Liu Xinyan’s stories in your inbox
Join Medium for free to get updates from this writer.
A simple feature requirement becomes something that the world and AI systems have to support over the long term.
That does not mean the relationship should not exist. If a MULE could be permanently stopped by a rock that the player can casually climb over, the entire pursuit would quickly fall apart.
And the doorway rule is unlikely to spread nearly this far. But both examples point to the same thing:
The rule itself may be simple. The expensive part may be everything else that starts depending on it.
Another Way a Rule Can Become More Complex
Systems do not become more complicated only because more things start depending on them.
Return to the doorway example. The player can crouch to prevent higher cargo from being knocked off. When Sam crouches, the cargo stack tilts forward with his body.
If the game wanted to pursue greater physical and visual precision, it could keep going: tilted cargo could continue colliding with the doorframe and still be knocked loose.
This is a different kind of complexity. Instead of connecting the rule to more systems, we are simulating the same interaction in finer detail.
More precise cargo collision could make the world feel more believable and make the outcome better match the player’s expectations of the physical relationship. It could also create more granular decisions, such as whether the current shape of the cargo stack can safely fit through the doorway.
But Death Stranding does not continue the simulation to that level. Once the player crouches, cargo that visually intersects with the doorway is not treated as colliding with it.
The existing rule already creates a clear decision: walk through normally and risk losing cargo, or crouch and move more slowly to keep it secure.
Greater simulation detail would not necessarily be without value. The question is one step further:
Are the additional decisions, feedback, and consistency worth making this interaction more complex?
How Far Is Worth Going?
The two examples above point to the same issue. A rule can expand outward by connecting to more systems, or inward by modeling the same interaction in greater detail.
Each additional step can make sense on its own. But “it makes sense” does not tell us how far we should go.
Designers do not necessarily make a wrong decision at any individual step. The problem is that we may stop comparing the value added at each new layer against the cost it introduces.
So the useful question is not simply, “Can we keep going?”
It is: What does the game actually gain by going this far?
Because when we add a rule, we are never adding only the rule itself. We are also adding everything that will have to keep supporting, accounting for, and remaining compatible with that rule later on.
