This section provides a foundational overview of UBF Studio and the UBF Projects it manages. Rather than focusing on a step-by-step walkthrough, our goal here is to explain the core concepts behind UBF Studio’s functionality and how it organizes blueprints and other artifacts into structured, self-contained projects. Establishing this understanding will better prepare you to navigate the tool effectively before delving into more detailed workflows.

​
UBF Projects

A UBF Project is a self-contained environment that manages and tracks a cohesive set of files—referred to as artifacts—and the relationships among them. Much like a Unity project or an Unreal Engine project, a UBF Project provides a structured way to organize your content and ensures that dependencies remain consistent, even as files evolve over time.

Under the hood, each file in a UBF Project is assigned a unique identifier (UID), and a corresponding .meta file is generated to maintain that UID and manage references. Rather than referencing files by path or name, UBF Studio uses these UIDs to tie artifacts together. This approach offers significant advantages:

  • Stable Referencing: UIDs remain the same regardless of file renames or moves, ensuring no broken links occur when reorganizing your project.
  • Consistent Lifecycle Management: UBF Studio can track dependencies across artifacts, warning you if a file deletion would break another blueprint or resource.
  • Seamless Collaboration: When a project is cloned or version-controlled, all references remain intact. Creators can confidently work across different machines or teams without losing any links or dependencies.

To preserve the integrity of file references within a UBF project, all file operations—including renaming, moving, or deleting—must be performed within UBF Studio. Actions taken outside Studio bypass the management layer, risking broken references or missing files.

​
UBF Project Artifacts

Within a UBF Project, there are three artifacts which you will predominantly work with:

  • Blueprints
  • Blueprint Instances
  • Resources

Each artifact serves a distinct purpose within your project. The next sub-sections will examine these artifact types and illustrate how they interconnect to form a cohesive UBF Project.

​
UBF Studio - Blueprints

A Blueprint is the core set of instructions that describes functionality such as how an asset is composed using UBF. A typical Blueprint is composed by piecing together a series of functional nodes—each node representing a discrete action or operation such as spawning a 3D model, applying a material, or incrementing a numerical value. By linking these nodes, you establish the flow of operations that the Blueprint will execute.

A Blueprint can invoke other Blueprints to handle specialized tasks. For example, a “Character Blueprint” might call an “Accessory Blueprint” to attach hats or jackets to the character, or a “Vehicle Blueprint” might reference multiple sub-Blueprints for its engine, wheels, or additional parts. This modular design ensures that complex behaviors can be broken down into smaller, more manageable logical units and thus promoting reusability and reducing redundant work.

There are three different variable types used by blueprints:

​
Blueprint Inputs

Inputs are parameters that other Blueprints or experiences can pass in when executing a Blueprint. Think of these as function arguments in a traditional programming language.

With Inputs, a single Blueprint can serve multiple scenarios. For instance, if you’re creating two versions of a jacket (one red and one blue), you don’t need to create separate Blueprints—just a single Blueprint with an Input parameter to define its primary color.

These inputs can be populated by Blueprint Instances (more on this below) and additionally, each Input can be assigned a default value to handle situations where a caller does not explicitly provide one.

​
Blueprint Variables

Variables are internal data slots within a Blueprint. Unlike Inputs, which are passed in externally, Variables are set and retrieved only within the scope of that Blueprint’s graph.

Variables enable state management as blueprints can store intermediate calculations, flags, or counters for later use. For example, you might track how many times a particular node has executed or whether a specific condition is currently met.

​
Blueprint Outputs

Outputs are values that a blueprint returns when its execution completes (or at designated points in the logic). They work similarly to return values in a programming language, allowing parent blueprints or external systems to retrieve calculated information from a child blueprint, such as a final numeric result, a newly spawned asset’s identifier, or a Boolean indicating success or failure.

All three variable types—Inputs, Variables, and Outputs—can store more than just primitive data types. They can hold references to complex objects, including Resources (e.g., textures, 3D models) or even other Blueprints. This flexibility means you can pass entire asset references around, dynamically inject sub-Blueprints, or store complex structures without needing separate artifacts.

​
UBF Studio - Blueprint Instances

A Blueprint Instance represents a unique instantiation of a Blueprint, specifying how the Input variables within that Blueprint are filled. If the Blueprint is akin to a class, the Blueprint Instance is akin to the constructed object—the instantiation that provides specific values for each exposed variable. This means creators can reuse one core Blueprint while assigning different resources and parameter values to create distinct outcomes.

Consider a “Character Blueprint” that spawns a humanoid model and applies a set of accessories. One Blueprint Instance might equip a Red Hat and Leather Jacket, while another instance uses a Blue Hat and Denim Jacket. Both instances rely on the same logic (the same Blueprint) yet produce unique results by supplying different variable bindings.

To illustrate further, imagine a pizza recipe serving as the Blueprint. The dough, sauce, and base ingredients form the core instructions—your “logic.” A single recipe can produce countless variations simply by changing the “toppings” parameter. One instance might have pepperoni and mushrooms, another might have onions and green peppers, but both are built off the same fundamental recipe. Likewise, Blueprint Instances allow you to adapt a single Blueprint to numerous scenarios with minimal redundancy.

Because Blueprint Instances control these variable bindings, they are crucial for efficiently managing variations without duplicating the core Blueprint logic. A single Blueprint can thus serve many purposes, drastically reducing maintenance and file clutter within the UBF Project.

​
UBF Studio - Resources

Resources represent the underlying data files—such as 3D models (.glb), textures, audio clips—that your UBF artifacts reference and rely upon. Unlike Blueprints or Blueprint Instances, Resources contain no logic. They serve purely as raw data for a Blueprint to reference at runtime.

While UBF Studio allows you to import and organize Resources, it is not a 3D modeling or asset-creation tool. You will first need to create or acquire these files (e.g., modeling them in a 3D software or designing them in an external application) before bringing them into your UBF project—much like importing a model or texture into Unity or Unreal.

Within UBF Studio, each Resource is assigned a unique identifier (UID) and tracked through a .meta file. When you design a Blueprint, you might call functions like SpawnMesh or ApplyMaterial and reference the UID of the relevant Resource (e.g., “BearBody” for a 3D model or “BearFurTexture” for a material). Because these references are UID-based, the linkage remains intact even if you rename or reorganize files within your project.

​
Exporting UBF Artifacts

When you export from UBF Studio, you select which Blueprint Instances you wish to include in the bundling process—whether that’s every instance in your project or just a specific subset. The export process then compiles these instances along with all referenced blueprints and sub-blueprints, stripping out Studio-specific features and reducing them to a runtime-ready format. At the same time, the process analyzes every artifact referenced by your chosen instances—such as additional Blueprints, textures, or 3D models—and collates their unique identifiers (IDs) into one or more Artifact Catalogs.

An Artifact Catalog is essentially a map from artifact IDs to the location of those files (locally or remotely). When a Blueprint Instance is executed by an interpreter at runtime and comes across a specific referenced resource (such as a texture), the Interpreter can leverage the catalog to look up the referenced ID and fetch the corresponding resource from its designated location.

Depending on your operational needs, you can maintain project-wide Artifact Catalogs or generate smaller catalogs alongside specific Blueprint Instances. While the IDs used inside your UBF project have no external meaning by themselves, leveraging a catalog ensures that any UBF Interpreter can resolve these references at runtime and execute your UBF functionality correctly.

NOTE: Exporting from UBF Studio generates local bundles that remain local to your environment. It does not automatically upload artifacts to a cloud-based host, nor does it update your Artifact Catalog with remote URLs. Documentation will be available for information on how to publish exported artifacts and assign remote URLs.