Begin With the System You Mean
General Systems Theory gives us a useful starting point: a system consists of interacting elements. Its behavior depends on relationships as well as individual parts.
A boundary distinguishes the system under consideration from its environment. It can be conceptual rather than a physical wall.
For a game, we need to say what we are examining.
The formal rules?
A particular match?
The people playing together?
A continuing campaign?
Those are related, but they are not identical.
If I examine the formal rules, player conversation may sit outside my chosen model and influence it through permitted decisions.
If I examine the whole play session, the players and their conversation belong inside it.
The boundary depends on the question.
The environment does not disappear because we leave it outside our model.
It remains something we may need to understand.
This is my application of systems thinking to game design. It does not replace the established meaning of a system or turn every design choice into a scientific law.
A Map Edge Is Only One Kind of Limit
A game board may have a visible edge.
A rulebook creates other limits.
Which actions are available?
Which resources count?
How is time represented?
What information can a player use?
What changes carry into the next session?
These questions define the scope and permitted operation of the game model.
They also need different answers.
A board edge tells us where pieces may move.
A rule about outside advice tells us whether information from another person may influence a player’s decision.
A campaign record tells us which earlier events remain relevant.
Treating all three as simply “the boundary” would hide useful distinctions.
Name the limit you are discussing.
Then ask what crosses it, by what route, and with what effect.
Decide What the Game Is About
Imagine a game about getting a caravan across a dangerous mountain pass.
This is an invented design example.
We could track individual meals, wagon repairs, weather, relationships, and the price of every item.
Or we could use three resources: supplies, time, and trust.
Neither choice is automatically correct.
What experience do we want?
If the interesting decisions concern scarce supplies and uncertain routes, detailed bookkeeping about kitchen tools may add little.
If the game concerns maintaining a traveling community, shared work and disagreements might deserve more attention.
The subject helps determine what belongs in the model.
The desired player decisions help determine how much detail those elements need.
Start there.
A design becomes easier to evaluate when we can explain why something is included.
Leaving Something Out Has an Effect
Suppose our caravan game tracks damage to wagons but assumes people recover fully between journeys.
Repairs now have a continuing cost.
Injuries do not.
Players may reasonably treat the wagons as the more important long-term concern.
That behavior would not be mysterious.
It would follow from what the game remembers.
Now suppose trust affects whether travelers share supplies.
A disagreement can change the next journey even when nobody loses equipment.
A different relationship has entered the model.
Leaving something out is often necessary. We cannot give everything equal attention.
But an omission can still shape behavior.
Ask what the game makes cheap, invisible, or easy to forget.
Then decide whether that supports the experience you intend.
Something Outside Can Still Matter
Return to the mountain pass.
We might decide not to simulate the region’s whole climate.
Weather can still enter the game through a defined procedure.
Draw a weather card at the beginning of each day.
Apply its effect to available routes.
Let the players respond.
Here, weather is represented within the fiction. The card procedure generates its game effect.
That is different from importing a real weather forecast during play.
A prewritten deck drawn during a match belongs to the match model if we include it there. A live forecast would bring new information from outside that model.
We need to describe the model before calling either arrangement open or closed.
Likewise, an RPG group can allow new fictional details to enter through conversation and Game Master judgment.
What someone proposes may become established information in the shared world.
The procedure for admitting that information matters.
Who has authority?
What must remain consistent?
Can another player challenge an interpretation?
A boundary can support exchange while still having clear rules.
Openness and Feedback Ask Different Questions
In systems analysis, openness concerns exchange with the environment across the selected boundary. The relevant exchange must be specified for the kind of system being studied.
Feedback concerns information about results returning to influence later behavior or control.
These concepts are related, but they are not interchangeable.
Imagine a player sees that spending supplies quickly leaves the caravan short near the summit.
On the next attempt, they conserve more.
The result informed a later decision.
That does not, by itself, tell us whether the game’s formal state model admits new environmental inputs during a match.
Nor does an unpredictable result prove that a system is open.
We can have uncertainty inside a deliberately limited model.
For game analysis, “comparatively closed” must always identify the boundary and exchanges being limited. It should not imply that people, physical components, or play sessions are literally isolated from the world.
That precision will matter when this series reaches its fuller discussion of open and closed systems.
More Detail Creates More Relationships to Manage
Suppose we add horses to our caravan game.
Now we need to consider feed.
Fatigue.
Load.
Perhaps recovery and replacement.
One addition can change several existing decisions.
A new resource is rarely just one more number.
What does it connect to?
Does it duplicate an existing resource?
Will players understand why it matters?
Does it create an interesting choice often enough to justify the attention it requires?
These are practical design questions.
Sometimes a single supply track handles the experience better than five separate inventories.
Sometimes combining everything erases the exact distinction the game needs.
Choose the detail that supports play.
Then examine the relationships it creates.
Put the Boundary Through Play
A written design can appear clear until someone tries something you did not anticipate.
Can a traveler share supplies after the daily cost has been paid?
Does a promise made during one journey affect the next?
Can the party abandon a wagon to save time?
If someone invents a clever repair, who decides whether it works?
These questions reveal how the design actually operates.
Watch for rules that contradict each other.
Watch for information players repeatedly request.
Watch for a cost that nobody considers because another action makes it irrelevant.
You may need a clearer procedure.
A different level of detail.
Or a larger change to what the game represents.
Test the revised choice again.
The goal is a game whose operation supports the decisions you want players to encounter.
Boundaries Can Give Choice a Shape
Limits can make choices understandable.
A player knows what they have.
What an action costs.
What information remains uncertain.
What can change.
That clarity can give improvisation somewhere useful to begin.
In The Game Doesn’t Tell the Story. The Players Do., I explore how decisions and consequences become a shared story.
Here, the design question comes one step earlier.
What have we given people to decide about?
What will the game notice when they act?
What can enter through their contributions?
What will remain outside the experience we are building?
We do not have to represent the whole kingdom.
We need to understand the part we have chosen, its important relationships, and how it connects to what surrounds it.
Choose the boundary deliberately. Then see what becomes possible inside it—and what still matters beyond it.
Systems Sources and Further Reading
The systems terminology draws on Ludwig von Bertalanffy’s General System Theory: Foundations, Development, Applications (1968), especially its discussion of interacting elements and open systems. The Systems Engineering Body of Knowledge provides accessible accounts of systems, their environments, and feedback. The caravan examples and design recommendations are my applications of those concepts.