Zum Hauptinhalt springen

Chapter 13

The Cube Runtime Pipeline

"Every Cube runtime object begins as authored knowledge and ends as executable reality."

Why This Chapter Exists​

The previous parts of this handbook introduced the philosophy behind the Cube Framework.

Definitions.

Operations.

Responsibilities.

Runtime Assembly.

Composition.

Each concept exists for a reason.

This chapter connects those ideas into a single architectural process.

It introduces one of the central ideas of the Cube Framework.

The Runtime Pipeline.

Thinking in Flow Instead of Objects​

Many gameplay systems are designed around objects.

Weapons.

Vehicles.

Characters.

Components.

The Cube Framework approaches the problem differently.

Rather than asking how an object behaves, it asks how information moves.

Every runtime object is the result of a series of architectural transformations.

Information progresses through multiple stages until it eventually becomes executable gameplay.

The runtime object is therefore not the beginning of the process.

It is the final product.

The Journey Through the Cube Framework​

Every Cube module follows the same high-level architectural flow.

Definitions
      │
      ▼
Build Pipeline
      │
      ▼
Runtime Assembly
      │
      ▼
Runtime State
      │
      ▼
Runtime Host
      │
      ▼
Gameplay
      │
      ▼
Replication

Although individual modules may extend this process, the overall flow remains remarkably consistent throughout the framework.

Every stage prepares the next.

No stage attempts to replace another.

Definitions​

Everything begins with authored knowledge.

Definitions describe what should exist.

They contain no temporary runtime state.

They perform no gameplay.

They merely describe possibility.

Whether constructing a weapon, a vehicle or another runtime system, every Cube module begins here.

Validation​

Before authored knowledge can become runtime, it must first be trusted.

Validation verifies structural correctness.

Required assets.

Dependencies.

Configuration.

Relationships.

Only validated information continues through the pipeline.

This protects every later subsystem from unnecessary defensive programming.

Build Preparation​

Once validated, information is transformed into a build representation.

This stage gathers everything required for Runtime Assembly.

Definitions remain untouched.

Instead, a working representation is created that contains all information required to construct the runtime object.

This representation exists only for the duration of the assembly process.

The result is often referred to as a Working Build.

It is no longer authored knowledge.

It is not yet runtime.

It is the framework's temporary working representation between both worlds.

Runtime Assembly​

Runtime Assembly transforms the prepared build into executable runtime objects.

Components are created.

Relationships are established.

Runtime ownership is assigned.

The runtime object now exists.

At this point, however, gameplay has not yet begun.

Assembly constructs.

It does not simulate.

Runtime Initialization​

Newly assembled runtime objects must now initialize their internal state.

References become valid.

Runtime systems establish communication.

Temporary initialization tasks complete.

Once initialization has finished, the runtime object becomes operational.

Its architectural construction is complete.

Networking​

If the runtime object participates in multiplayer, networking now becomes responsible for synchronization.

Authority.

Ownership.

Replication.

Late Join.

Network Culling.

The runtime object begins existing consistently across connected machines.

Importantly, networking does not alter the architectural identity of the object.

It merely distributes its runtime state.

Gameplay​

Only after every previous stage has completed does gameplay finally interact with the runtime object.

From the perspective of gameplay, the object simply exists.

Everything required to create it has already happened.

Gameplay therefore remains focused on interaction rather than construction.

This separation is one of the defining characteristics of the Cube Framework.

One Pipeline, Many Modules​

The Runtime Pipeline belongs to the Cube Framework.

Not to the Weapon Framework.

Not to future Vehicle modules.

Not to Equipment.

Individual modules may introduce additional stages.

Some stages may become more sophisticated.

The overall architectural flow remains the same.

Every module benefits from a familiar foundation.

Design Note​

Whenever introducing a new subsystem into the Cube Framework, avoid asking:

"Where should this class live?"

Instead ask:

"At which stage of the Runtime Pipeline does this responsibility belong?"

The pipeline should organize responsibilities.

Classes simply implement them.

Framework Law XIII​

The Cube Runtime Pipeline transforms authored knowledge into executable gameplay through a sequence of clearly separated responsibilities.

Every subsystem participates in the journey.

No subsystem owns the entire journey.

Looking Ahead​

Understanding the Runtime Pipeline explains how information moves through the Cube Framework.

The next chapter explores how architectural responsibilities are distributed across specialized layers, ensuring that every stage of the pipeline remains focused on a single purpose.

Revision History​

Version 1.0​

Initial publication.