Chapter 1
Rethinking Runtime Objects
"The most important decision in a framework is often made long before the first object is ever created."
Why This Chapter Exists
Before discussing the Cube Framework, we must first challenge one of the most common assumptions in software development.
When developers think about gameplay systems, they naturally think about objects.
Weapons.
Vehicles.
Characters.
Items.
Actors.
Components.
The conversation almost always begins with what these objects are.
The Cube Framework begins somewhere else.
It begins by asking a different question.
Should runtime objects be the foundation of the architecture at all?
This question appears surprisingly simple.
Yet its answer influences almost every architectural decision that follows.
The Traditional Perspective
Most gameplay systems are designed around runtime objects.
An object is created.
Behavior is attached.
State is modified.
Gameplay begins.
As projects grow, additional responsibilities naturally accumulate.
Networking.
Saving.
Replication.
Customization.
Validation.
Animation.
Eventually, the runtime object becomes responsible for almost everything.
This evolution rarely happens intentionally.
It happens because runtime objects are always available.
Whenever a new feature is required, adding "just one more function" feels convenient.
Months later, convenience becomes complexity.
A Different Starting Point
The Cube Framework deliberately avoids treating runtime objects as the center of the architecture.
Instead, runtime objects are viewed as temporary representations of architectural knowledge.
They are important.
They are visible.
But they are not authoritative.
The authoritative source of knowledge exists elsewhere.
Runtime objects simply make that knowledge executable.
This distinction is subtle.
Its consequences are enormous.
Objects Are Temporary
Every runtime object eventually disappears.
Actors are destroyed.
Components are recreated.
Levels unload.
Clients reconnect.
Servers restart.
If the architecture depends entirely on runtime objects, valuable information disappears together with them.
The Cube Framework therefore separates knowledge from execution.
Knowledge survives.
Runtime representations do not.
This simple principle makes systems significantly easier to rebuild, synchronize and extend.
The Architectural Shift
Thinking this way requires abandoning a familiar assumption.
Instead of asking
"How should this object behave?"
the framework asks
"Which knowledge should eventually become a runtime object?"
Once this question changes, architecture begins changing with it.
Definitions become more important than actors.
Assembly becomes more important than spawning.
Lifecycle becomes more important than construction.
The framework gradually stops revolving around objects.
It begins revolving around information.
Looking Ahead
This idea may initially feel abstract.
The following chapters gradually introduce the concepts that make this possible.
Definitions.
Builds.
Operations.
Runtime Assembly.
Responsibilities.
Together, these concepts form an architecture where runtime objects are no longer the beginning of the story.
They are the result.
Design Note
The Cube Framework does not attempt to eliminate runtime objects.
They remain essential.
The framework simply assigns them a different role.
Rather than becoming the source of architectural truth, runtime objects become the final representation of information that already existed before they were assembled.
Framework Law I
Runtime objects execute architecture. They should rarely define it.
Understanding this distinction is the first step toward understanding the Cube Framework.
Revision History
Version 1.0
Initial publication.