DevLog 2025801: Procedural Context Type

Overview

In our pursuit to challenge existing visual paradigms and establish the next-generation general-purpose visual programming system, we've studied, borrowed from, and questioned many design elements of existing systems.

An area of innovation in Divooka is its hybrid use of dataflow and procedural contexts - each suited for particular use cases.

Another innovation, still in its infancy and improving through trial and error, is what we call the procedural context base type.

Introduction

The need for this concept emerged as we integrated procedural contexts and re-examined the pain points of working with advanced visual programming systems like Unreal Blueprint. Changing the base type of Blueprints often leads to disastrous outcomes.

We aim to provide a smoother experience. In Divooka, the procedural "base type" is a toggle - you can quickly switch a graph to a different base type. Everything that isn't type-dependent continues to work, and any function that is type-dependent simply indicates so.

Components

The procedural base type introduces four important concepts:

1. Procedural base type (current anchor): The current graph's base, representing the instance that functions in the graph are called on.
2. Procedural runner for any given base type: When a run is triggered, Divooka allows a custom runner to determine what actually happens. In a typical program, this runner might seek the "entry" function (e.g., Start) and execute from there. In higher-level frameworks, it might look for recognizable event bindings.
3. Procedural base type instance override: By default, the specified base type is instantiated at runtime to provide a concrete instance. However, the runtime can also supply a compatible instance for the graph's behavior to operate on. This allows flexibility and decouples implementation (runtime instance) from behavior specification (graph design).
4. Divooka graph-baked procedural instance type: It may be desirable to directly convert or interpret a graph as a concrete type. The main benefit is being able to pass the graph as a type for further processing. This feature is not yet implemented.

Based on the above, three key objects are involved in evaluating a procedural context graph:

1. Executer: Provides the logic and mechanisms to fetch and evaluate specific execution paths in the procedural graph.
2. Runner: Determines what to run and in what order, on an event level. It may also provide additional runtime data required by the instance.
3. Instance: Represents the runtime state of the graph.

Summary

In summary, a Divooka graph is a data structure that specifies behavior, while the runtime interprets and is responsible for actual execution. This makes Divooka a data-driven and highly extensible programming system suitable for various scenarios.

By combining the scripting nature of Divooka graphs with the compiled/JIT-accelerated nature of the runtime, Divooka offers both flexibility and dynamic richness - while minimizing friction in program development.