Introduction

The scripting engine is the final piece that allows gameplay code; whether written in Rust or authored through Blueprints; to interact with the world at runtime.

Rather than exposing raw pointers or direct object references, gameplay code will operate on lightweight references that internally resolve to handles into SceneDB. These handles provide stable access to actors and their components while allowing SceneDB to remain the authoritative source of truth for object lifetime, serialization, networking, and editor integration.

Once a reference has been resolved, the scripting runtime will be able to invoke methods on actors, query and modify component data, and interact with reflected types through the Pulsar Reflection system.

This architecture provides a unified programming model regardless of whether gameplay logic originates from native Rust code or Blueprint graphs. Every scripting backend ultimately communicates through the same reflection layer, ensuring consistent behavior across the engine.

Completing this work is a major milestone for Pulsar. It transforms the engine from a collection of rendering, scene management, and tooling systems into a platform capable of supporting complete gameplay.

With the scripting engine, SceneDB integration, and reflection working together, Pulsar will have all of the core runtime systems necessary to support a late-stage alpha or early beta release. Afterward, the primary focus shifts toward polishing the build pipeline, reconnecting the level editor to SceneDB, and expanding gameplay features rather than building fundamental engine infrastructure.

---

Current Blockers

There are two remaining architectural pieces that must be completed before the scripting engine can be fully implemented.

1. SceneDB as the Source of Truth

The entire engine—including the level editor—must rely exclusively on SceneDB for world state.

This work is tracked in:

• https://github.com/Far-Beyond-Pulsar/Helio/issues/121

At the moment, this effort is blocked by the design of SceneDB's Subsystems API. The implementation plan is still being finalized, after which a dedicated GitHub issue will be opened. The API is currently being designed by @tristanpoland, @sepehrnour, and @Tuafo.

Once complete, every runtime and editor system should resolve actors, components, and object relationships through SceneDB instead of maintaining parallel state.

2. Reflection Runtime Method Support

The Pulsar Reflection runtime must support invoking methods on reflected runtime types; not just inspecting fields and metadata.

This functionality is required so that the scripting engine can dynamically dispatch methods regardless of whether they originate from:

• Native Rust types
• Engine components
• User-defined gameplay classes
• Blueprint-generated classes

Without runtime method invocation, scripting would be limited to field inspection and would be unable to call gameplay APIs in a generic manner.

---

Scope of This Issue

This issue implements the runtime infrastructure required for scripting to communicate with SceneDB and the reflection system.

Specifically, this includes:

• Implement stable object references backed by SceneDB handles.
• Provide a runtime API for resolving handles into actors and components.
• Integrate Plugin_Blueprints and PBGC with the new reflection method invocation system.
• Route Blueprint function calls through the reflection runtime instead of bespoke dispatch logic.
• Restore type-aware node filtering within the Blueprint editor so dragging from a pin only displays functions and nodes compatible with that type.
• Ensure reflected methods expose sufficient metadata for Blueprint discovery, overload resolution, and parameter validation.
• Support invoking methods on both actors and reflected component types.
• Validate object references before invocation and gracefully handle destroyed or invalid SceneDB handles.
• Ensure the runtime dispatch layer is shared between Rust scripting and Blueprint execution to avoid duplicate implementations.
• Lay the groundwork for future scripting backends by making the reflection invocation API language-agnostic.

---

Expected Outcome

Once this issue is complete:

• Rust gameplay code can safely reference and manipulate SceneDB actors.
• Blueprint graphs can invoke reflected methods through the same runtime dispatch layer.
• Actors and components become fully scriptable through the reflection system.
• The Blueprint editor regains intelligent, type-aware node filtering.
• SceneDB becomes the single authoritative runtime database for engine state.
• Future scripting languages can be implemented without requiring engine-specific dispatch code.