Chapter 14
Layers of Responsibility
"The Cube Framework does not organize systems by type. It organizes them by responsibility."
Why This Chapter Exists
The previous chapter introduced the Cube Runtime Pipeline.
Information moves through the framework until it eventually becomes executable gameplay.
Understanding the flow of information explains when work happens.
It does not yet explain who should perform that work.
The Cube Framework answers this question through architectural responsibility.
Every subsystem belongs to a specific layer of responsibility.
These layers are not defined by inheritance.
They are not defined by module boundaries.
They are defined by purpose.
Responsibilities Create Layers
Many software architectures organize systems according to technology.
Rendering.
Networking.
Physics.
Gameplay.
The Cube Framework takes a different approach.
It organizes systems according to responsibility.
Each layer answers one architectural question.
Nothing more.
As responsibilities change, layers may grow.
Their purpose should not.
The Definition Layer
The first responsibility layer contains authored knowledge.
Definitions.
Configurations.
Asset references.
Gameplay Tags.
Relationships.
This layer does not execute gameplay.
It does not know anything about runtime.
Its responsibility is simply to describe what can exist.
The Build Layer
Once authored knowledge has been accepted, the framework begins preparing runtime construction.
The Build Layer collects, validates and prepares the information required for Runtime Assembly.
It answers questions such as:
- Is this configuration complete?
- Which resources are required?
- Which runtime systems will participate?
Nothing is created yet.
The layer exists solely to prepare construction.
The Runtime Layer
The Runtime Layer transforms prepared information into executable runtime systems.
Objects now exist.
Components now exist.
Relationships now exist.
The Runtime Layer is responsible for construction.
Not gameplay.
Once runtime assembly has completed, its primary responsibility is fulfilled.
The Networking Layer
If a runtime object participates in multiplayer, networking becomes responsible for synchronization.
Ownership.
Authority.
Replication.
Late Join.
Network relevancy.
The Networking Layer distributes runtime state.
It does not define gameplay.
It does not assemble runtime objects.
Its responsibility remains intentionally narrow.
The Gameplay Layer
Gameplay represents the final consumer of the framework.
By the time gameplay begins interacting with a runtime object, every previous architectural layer has already completed its work.
Gameplay therefore focuses exclusively on interaction.
Not construction.
Not synchronization.
Not validation.
This separation keeps gameplay systems remarkably small despite increasingly sophisticated infrastructure.
Layers Are Responsibilities, Not Dependencies
One common misunderstanding is that layers should directly control one another.
The Cube Framework deliberately avoids this.
A layer exists only to fulfill its own responsibility.
It prepares information.
Transfers responsibility.
Then steps aside.
The architecture therefore behaves less like a hierarchy...
...and more like a relay race.
Every participant contributes.
None attempts to run the entire course alone.
Stability Through Separation
As new Cube modules are introduced, new runtime capabilities naturally appear.
Vehicles.
Equipment.
Characters.
Interactive world objects.
Although these modules solve different gameplay problems, their architectural layers remain remarkably similar.
Definitions still describe.
Builds still prepare.
Runtime still assembles.
Networking still synchronizes.
Gameplay still consumes.
This consistency is one of the defining characteristics of the Cube Framework.
Design Note
When introducing a new subsystem, avoid asking:
"Which module should own this?"
Instead ask:
"Which architectural responsibility does this system fulfill?"
Responsibilities determine layers.
Modules merely contain implementations.
Framework Law XIV
Within the Cube Framework, layers exist to separate responsibilities—not technologies.
When responsibilities remain clear, every future Cube module inherits architectural consistency without inheriting unnecessary complexity.
Looking Ahead
Understanding the responsibility layers explains how the framework is organized.
The next chapter follows information more closely by exploring how a runtime object is assembled from authored knowledge into executable runtime state.
Revision History
Version 1.0
Initial publication.