Zum Hauptinhalt springen

Chapter 15

The Build Pipeline

"Within the Cube Framework, runtime objects are never created directly. Every runtime begins as a prepared Build."


Why This Chapter Exists

The previous chapters introduced the architectural philosophy of the Cube Framework and the Runtime Pipeline.

Between authored definitions and executable runtime objects lies another important architectural step.

The Build Pipeline.

Within the Cube Framework, runtime objects are never assembled directly from authored data.

Instead, every runtime object is first represented by a Build.

This Build contains all information required to safely construct a runtime object.

Separating preparation from construction is one of the core architectural decisions of the Cube Framework.


The Purpose of a Build

A Build represents a complete description of a future runtime object.

Within the Cube Framework, the Build is intentionally mutable.

It exists as a temporary working representation that can collect additional information before Runtime Assembly begins.

Once Runtime Assembly completes successfully, the Build has fulfilled its architectural responsibility.

It is no longer part of the active runtime representation.

It is not gameplay.

It is not networking.

It is not an Actor.

It is not a Component.

Instead, it is an architectural representation of everything required for Runtime Assembly.

The Build exists to remove uncertainty before runtime construction begins.

By the time Runtime Assembly receives a Build, every required piece of information should already be available.


Why Cube Uses a Build Pipeline

Without a Build Pipeline, Runtime Assembly would need to solve multiple problems simultaneously.

It would have to:

  • discover definitions,
  • resolve dependencies,
  • validate configurations,
  • prepare runtime data,
  • and finally assemble the runtime object.

This would give Runtime Assembly too many responsibilities.

The Cube Framework deliberately avoids this.

Instead, the Build Pipeline prepares all required information before construction begins.

Runtime Assembly then focuses exclusively on creating runtime objects.


Build First, Assemble Second

One of the architectural principles of the Cube Framework is that preparation always precedes construction.

A Build answers questions such as:

  • Which Definitions participate?
  • Which assets are required?
  • Which runtime systems will be created?
  • Which configuration is valid?
  • Which relationships already exist?

Only after these questions have been answered does Runtime Assembly begin.

This predictable sequence makes runtime construction deterministic and repeatable.


Temporary Infrastructure

A Build is intentionally temporary.

Its purpose is fulfilled the moment Runtime Assembly completes successfully.

After that point, gameplay no longer interacts with the Build itself.

Instead, gameplay interacts with the runtime representation created from it.

For this reason, Builds should never become long-lived gameplay objects.

They belong to the infrastructure of the Cube Framework rather than to the gameplay layer.


Reusable Across Every Cube Module

The Build Pipeline is not exclusive to the Weapon Framework.

It represents an architectural concept shared by every Cube module.

A Weapon Build prepares a weapon.

A Vehicle Build prepares a vehicle.

An Equipment Build prepares equipment.

Although the authored data differs, the architectural responsibility remains identical.

Every Cube module prepares before it assembles.


Separation of Responsibilities

The Build Pipeline exists for one responsibility only.

Preparing runtime construction.

It does not assemble runtime objects.

It does not initialize gameplay.

It does not synchronize networking.

Those responsibilities belong to later stages of the Cube Runtime Pipeline.

By limiting the Build Pipeline to preparation, every subsequent subsystem receives reliable and predictable input.


Design Note

Whenever new information becomes necessary during Runtime Assembly, consider whether that information should have been prepared by the Build Pipeline instead.

Preparation should happen before construction whenever possible.


Framework Law XV

Within the Cube Framework, runtime construction begins only after preparation has been completed.

The Build Pipeline creates certainty.

Runtime Assembly transforms that certainty into executable runtime objects.


Looking Ahead

With a prepared Build available, the Cube Framework can finally begin creating runtime objects.

The next chapter explores Runtime Assembly, where authored knowledge becomes an executable runtime representation.


Revision History

Version 1.0

Initial publication.