Zum Hauptinhalt springen

Chapter 17

Runtime Identity

"Within the Cube Framework, every runtime object is more than an Actor. It is a uniquely identifiable architectural entity."

Why This Chapter Exists​

By the time Runtime Assembly has completed, a runtime object exists within the world.

It can participate in gameplay.

It can communicate with other systems.

It can eventually replicate across the network.

At this point, however, another architectural problem appears.

How does the framework refer to this runtime object?

More importantly:

How does every participating subsystem know that it is referring to the same runtime object?

The Cube Framework answers this through Runtime Identity.

More Than an Actor​

An Actor already possesses an identity within Unreal Engine.

It has a memory address.

It has an object name.

It exists inside the World.

For gameplay this is often sufficient.

For the Cube Framework it is not.

The framework requires an identity that survives architectural communication.

Subsystems should never depend on temporary implementation details when referring to runtime objects.

Instead, they communicate through a shared architectural identity.

Architectural Identity​

Runtime Identity represents the architectural existence of a runtime object.

It answers questions such as:

  • Which Build created this runtime object?
  • Which runtime systems belong to it?
  • Which networking systems synchronize it?
  • Which gameplay systems currently reference it?

Rather than identifying implementation details, Runtime Identity identifies the runtime object as a participant within the Cube Framework.

Identity Remains Consistent​

Many systems interact with the same runtime object.

Runtime Assembly creates it.

Networking synchronizes it.

Gameplay consumes it.

Future systems may save it.

Debugging tools may inspect it.

Although every subsystem performs a different responsibility, they should all refer to the same architectural entity.

Runtime Identity provides that consistency.

Identity Is Not Ownership​

One important distinction must be made.

Identity does not imply ownership.

Knowing that a runtime object exists does not grant authority over it.

Networking determines authority.

Gameplay determines interaction.

Runtime Identity simply allows every subsystem to agree on which runtime object they are discussing.

This separation keeps communication independent from responsibility.

Identity Throughout the Runtime Lifecycle​

Runtime Identity exists for the entire lifetime of a runtime object.

It is established during Runtime Assembly.

It remains stable while the object participates in gameplay.

It disappears only when the runtime object itself ceases to exist.

This predictable lifecycle allows every Cube subsystem to communicate using a shared architectural reference.

Why Runtime Identity Matters​

As the Cube Framework grows, more systems will interact with every runtime object.

Weapons.

Vehicles.

Equipment.

Characters.

Editor tools.

Save systems.

Analytics.

Debugging utilities.

Every one of these systems benefits from speaking the same architectural language.

Runtime Identity provides that language.

Rather than every subsystem inventing its own way of identifying runtime objects, the framework establishes one shared concept.

A Foundation for Future Modules​

Runtime Identity is not exclusive to the Weapon Framework.

Every future Cube module relies on the same architectural idea.

Regardless of which runtime object is assembled, it becomes a uniquely identifiable participant within the framework.

This consistency allows future modules to cooperate naturally without redefining how runtime objects are recognized.

Design Note​

Whenever a subsystem needs to reference a runtime object, avoid asking:

"How can I identify this Actor?"

Instead ask:

"Which Runtime Identity am I interacting with?"

Identity should represent the architectural entity rather than the implementation that currently hosts it.

Framework Law XVII​

Within the Cube Framework, runtime objects are identified architecturally before they are referenced functionally.

Shared identity enables consistent communication across every subsystem.

Looking Ahead​

Runtime State describes what currently exists.

The next chapter explores how individual runtime elements are composed into a coherent runtime representation capable of supporting gameplay.

Revision History​

Version 1.0​

Initial publication.